Re: Enforcing Code Feature Requirements in C++
Posted: Sep 24, 2008 5:38 PM
> Interesting metaprogramming, but I am not convinced that
> this approach would really improve software quality for
> real-world projects.
I probably should have mentioned in the article that this problem was posed to me by a client. They were developing games running across the internet, and they had the notion of "deterministic" code, which, as best I can recall, was code that yielded exactly the same results, regardless of the platform on which it was run. Some of their functions were "deterministic" and some were not, and they asked me if I could think of a way to make it impossible for "deterministic" functions to call ones that were not "deterministic."
I think that if we had tools to enforce code features, we'd find all kinds of places where they were useful.
> Everything is still based on programmer discipline. How
> does a "threadsafe" tag save me from calling strerror()
> instead of strerror_t()?
Enforcing code features doesn't save you from all your errors, but it gives you a tool to enforce certain interface contracts that are currently invisible to compilers. Think of it as a new feature of the type system. If you find type systems useful, I'd hope you'd see that this new feature could help prevent certain kinds of errors.
> Also, properties like "threadsafe" or "portable" are very
> hard to define and will probably change their meaning over
> time. This looks like a maintainance-nightmare to me.
Current code already depends on code features, and the definitions of those features are already subject to change. If the definition of some feature (such as "thread safe") changes, functions that depend on the new definition will likely behave improperly when calling functions offering only the old definition. We currently catch such errors via code reviews, testing, and debugging. Using the approach I describe, we'd just change the name of the code feature (e.g., from "ThreadSafeV1" to "ThreadSafeV2", possibly having the latter inherit from the former, as suggested in the "Open Issues" section of the article), update the code to use the new feature names in the appropriate places, and recompile. If the result was not consistent, the compiler would complain. I don't see how this would be any worse than the way we currently do things, and I'd expect it to be better.