Slashdot Mirror
Bjarne Stroustrup On Concepts, C++0x
An anonymous reader writes "Danny Kalev has an interview with Bjarne Stroustrup about the failure of concepts, the technical issues of concepts, whether the ISO committee's days are over, and whether C++ is at a dead-end. 'I don't think that concepts were doomed to fail. Also, I don't think concepts were trying to fix many things or to transform C++ into an almost new language. They were introduced to do one thing: provide direct language support to the by-far dominant use of templates: generic programming. They were intended to allow direct expression of what people already state in comments, in design documents, and in documentation. Every well-designed template is written with a notion of what is required from its arguments. For good code, those requirements are documented (think of the standard's requirements tables). That is, today most templates are designed using an informal notion of concepts.'"
Templates are what Python calls 'duck typing'. ("If it looks like a duck and quacks like a duck...") Why not just do that? You could add methods for introspection and so forth...
My blog
I've seen a lot of people dramatize about concepts being removed from C++0x.
Really, it's no big deal. There are alternative solutions, like some based on SFINAE -- that has now been extended to arbitrary expressions --, that provide almost the same feature set, the same quality in error messages, and are not much harder or more verbose to write or use.
Actually, getting rid of concepts was probably the best solution for C++0x, since they were a lot of work to implement on top of not being that well polished, not integrating that well with the rest (concepts are not types, nor are they templates, they're a whole new category of things) which would probably have led to different categories of compliance to the new standard.
This even gives a new chance to more vital features, such as polymorphic lambdas (understand lambdas were the types of the arguments is not given and which thus exhibit parametric polymorphism), to now being reconsidered.
It is a big deal. The two most important things concepts were going to do was make generic programming in C++ (1) explicit and (2) accessible.
Currently, generic programming in C++ is supported through a number of template meta-programming patterns and practices, most of which exist as Boost tribal knowledge - hail King Dave!* It is implicit in many library designs, but there is nothing enforcing it at the language level. If you're not familiar with the concepts of generic programming (pun intended), it's easy to mistake what's going on in the standard libraries as something else. This is especially true if your primary use of the STL is to have polymorphic container classes - you might just design a generic extension to another language that completely misses the point of generic programming (see Java Generics).
At a more fundamental level, a lot of the power in generic programming comes from the specializations that are possible when you meet type requirements. Right now, there is no way, outside the documentation, to state requirements and possible specializations. Making this explicit in the language makes it clear to the library user what the requirements are and what specializations are available.
This leads into the accessibility problem. Generic Programming using template meta-programming is difficult. To use it, you have to understand both the template system and generic programming. The former is defined in the standard, but the latter, as mentioned above, is tribal knowledge. By making generic programming explicit in the language, it immediately becomes accessible to a large number of developers who didn't have the time, patience, or fortitude (dealing with the Boost mailing list requires a large supply of this) to become proficient with template-based generic programming.
As an analogy: consider object-oriented programming in C. Prior to (and even after) C++, lots of OO code was been developed in C. But, each object system was different and based on local best-practices. C++ (and Objective-C) took those practices and codified them into a language extension. As soon as that occurred, one method for OO was standardized. Developers no longer had to implement their own object systems and adhere to documented (but not language enforced) policies. And, with a standard set of rules around this flavor of OO, many other developers felt comfortable jumping in the the fray.
Concepts in C++ should have had the same effect for Generic Programming in C++ that C++ had for Object Oriented Programming in C. The should have democratized generic programming and brought forth a renaissance in C++ library design. Instead, petty politics killed the most exciting change to C-like languages in years.
-Chris
*(Dave - I mean that in the nicest sense... you've done a great job with Boost (oh, we need to jam again, too)).
It's kind of sad. The C++ committee has taken the general position that the underlying defects of C++ should be papered over by making it possible to write templates that hide the problem. But the hiding never quite works; the mold always seeps through the wallpaper.
The root of the problem is that C and C++ backed into a type system. Originally, C barely had types at all; there were ints and there were floats. Pointers and ints were almost interchangeable. Fields in structures were just offsets, and field names had to be unique across all structures. Gradually, C evolved into a strongly typed language. Sort of. "void *" was introduced as a sort of escape hatch for the type system.
More importantly, there was never a clear distinction made between arrays and pointers. That single design decision is responsible for most of the buffer overflows in the world. We should have had syntax like
int read(int fd, char buf[n]&, size_t n);
to replace the old
int read(int fd, char *buf, size_t n);
which says nothing about the size of the array. Right there is the cause of most buffer overflows - the language doesn't properly support talking about the size of arrays.
Part of the problem there was a major error in the original design of C++ - it didn't have "&" references. So you couldn't talk about a reference to an array; you had to use a pointer to the first element. That pointer has the type of the element, not of an array. Every time you write "char *buf" instead of "char buf[n]&", you're lying to the compiler. The cost of that lie is millions of crashes a day.
Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.
Then the STL approached iteration as an extension of pointer arithmetic. For "compatibility" with C pointer arithmetic, iterators are not only unchecked, but are not explicitly bound to the collection over which they iterate. So the safety problems of C were carried over into STL arrays. This was another bad decision. Most modern languages approach iteration by providing a "do this to all that stuff" construct used for most common iteration cases. C++ does not.
This is why I'm so critical of the C++ committee. If they'd focused on safety, instead of cool but obscure template features, software would be much better today.