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.'"
What the hell? Do I have to RTFA to find out what C++0x is supposed to mean?
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
If C++ had a set of GUI libraries that were part of the standard and could be counted on to be in every compiler...
Hate to bust your bubble there sonny, but the new C++ specification has ALL SORTS of crap that won't translate to a lot of platforms. For instance, multithreading will be built into the language... but what about something like DOS where there is no threads? Or something that uses bazaar threading mechanisms like protothreads/contiki?
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
I wrote the original post on Lambda calling C++ a dead end, and I think what the article says about the standardization process is pretty accurate.
Essentially there are a set of issues real world C++ programmers must deal with when using the languages, particularly in large projects, that are never addressed by the standards committee. Enumerating a few by importance:
1. Stability, security, and memory safety.
Support for garbage collection, optional safe arrays, safe pointers, and bounds checking for sections of code. Code areas where reinterpret casts and other memory unsafe operations can be disabled and flagged as errors. Secure versions of the standard libraries. Etc.
Can anyone honestly say that security and stability in C++ code is not the singular most important issue for C++ presently? How many times have security, stability, or memory safety been even mentioned in the C++ 0x standardization process? I've browsed through many of the papers and have yet to see it mentioned a single time (possibly there are one or two mentions in the GC papers).
2. Ability to integrate with other languages, particularly managed and dynamic languages.
Reflection support, decidably parsable declarations, support or standardization of in/out semantics on declarations, etc. I would say for many (if not most projects) dealing with the "C++ as an insular world unto itself" is one of the next most glaringly problematic aspect of the language. Few languages go to greater lengths to make integrating with the outside world more difficult.
3. Issues with separate compilation, headers and macros.
BS made a half hearted attempt to mitigate the issues arising from the use of the include file model, and macros in C++, but it was quickly abandon. The problems (particularly in large projects) with the separate compilation model, (increasing time involved in parsing large headers), problems with macro leakage, and other issues in the essentially broken C style compilation model are a major source of continuous pain for C++ programmers.
There is no reason why the language can not continue to be backwards compatible with separate compilation and macros, but can be moved forward towards a more workable model for new code.
4. The inability to ever "deprecate" features.
The language can be progressively improved, but only by some sort of an official program of scheduling certain features for deprecation. Insecure C functions and libraries, unused standards, etc. This kruft unneccessarily complicates the introduction of new useful features, and makes it difficult to maintain production code (which typically become new code combined with a random collection outdated programming practices and library includes which must constantly be "code reviewed" out).
5. The inability to add features from other languages that do actually work.
What is important and "works" for one programmer is a superfluous and useless add-on for another. But there are features of java, C#, and dynamic languages that C++ would do well to imitate. These features are rarely even discussed in favor of serving the template meta-programming community and those who feel the language should add a host of other esoteric features to the corner case use scenarios of the language.
I've been writing C++ for more than 20 years, and I've dealt first hand working with a huge C++ project when working with ILM's large code base that exposed more than a few of the gaping weakness of this language. I was looking forward to.. at least.. some help in dealing with the impossibility of maintaining large amounts of template code, of which that code base had multiple nested layers. An error in one template parameter class cascades downwards into an infinite incomprehensible mess of template substitution errors. But the committee says "No concepts for you!"