The Next C++

Via Slashdot. Bjarne Stroustroup, the "designer and original implementor" of the C++ programming language, gives a look forward at the features most likely to be included in the next version of C++, titled C++0x (possibly one of the worst symbol ever for a programming language version).

I was surprised to learn from this article that the next version of C++ won't likely be ready until 2009. They've been batting around ideas for this version for awhile (the last version of C++ was C++98). On one hand it's great that developers and compiler/IDE implementors will be able to keep up with the new versions of the language. On the other hand, it seems to cast a negative shadow on the slow-moving process when compared to other technologies (like web technologies for instance). After all, a lot happens in 3 years (let alone 11 years) in the technology space.

According to Stroustroup, the committee is made of up volunteers who all have "day jobs", so that explains the pace to some degree. Anyway, I somehow get the feeling that the process is moving at a deliberate pace to give time for the market to absorb changes from the last version to see what worked, what didn't and what needs are out there. I don't think the C++ committee feels they need to compete with other technologies since C++ is so well-established in its very wide niche. This isn't to say that C++ doesn't need an upgrade - I agree with Stroustroup, the overall syntax for generic programming in C++ currently sucks (not a big surprise since, if I understand things correctly, generics were thrown in almost as an after-thought in the original C++ design).

Anyway, the underlying goals of committee are noble:

• Provide stability and compatibility (with C++98, and, if possible, with C)
• Prefer standard library facilities to language extensions
• Make only changes that change the way people think
• Prefer generality to specialization
• Support both experts and novices
• Increase type safety (by providing safe alternatives to currently unsafe facilities)
• Improve performance and ability to work directly with hardware
• Fit into the real world

Stroustroup doesn't give away much, since nothing is absolutely firm yet. But here's an example of some code that would align with some of the things he talks about:

Proposed C++0x code:

Equivalent C++89 code:

I know which version I prefer!

The idea of the "auto" is great - it means "figure out which type I need". This is fantastic for iterators like the above example - now if I change my underlying container to a std::list, I don't need to change the iterator type (or write a typedef for it), the compiler will pick up the change automatically. Of course you could use the C++98 version if you want to automatically typecast the iterator to some other type but clearly the "auto" idea makes great sense. Anyway, the idea is to eliminate all that unnecessary typing: Why should I have to do all that typing when vec.begin() returns a std::vector<double>::iterator in the first place? I welcome this addition to the language but it may make some programmers lazier in the long run. I can just see people putting "auto" every place instead of looking up the return types of functions and then getting into trouble with casting operations later - hopefully compiler warnings will keep us in line.

The ability to initialize a user-defined container via a list is less important to me, but it is appreciated since it puts user-defined containers almost on par with arrays and structs.

Stroustroup also mentions the idea of concepts which he describes as a "type of a type". In this facility, you specify within a template declaration what properties a template argument must have in order to be properly used within a template. This is used today, I remember Alexandrescu's Loki library as described in "Modern C++ Design", which uses this heavily. But if I understand Stroustroup here, the proposed where clause would allow for less cryptic compiler error handling up-front and to disambiguate "between templates taking the same number of arguments". I'll be interested to see this one when it's fully baked because, as a C++ geek, I'm obliged to be a fan of generic programming 😉

Stroustroup also mentions many of the libraries he would like to see in the next version of the Standard Template Library (STL). I'd personally like to see all of the following standardized now (that way I wouldn't have to worry about including the correct header files in my projects):

• Boost.Filesystem - for dealing with directories and files
• Boost.bind, Boost.mem_fn, Boost.Function - for function binding, callbacks
• Boost.Thread - for multi-threaded programming
• Boost.Spirit - for inline parsing of EBNF grammars

You could make arguments that Filesystem and Spirit are outside the core language principles and should stand as separate libraries, but this is my pet list after all so nyah!