Recently I've read on my local German C++ forum* that's there was a new draft document for C++09 Standard** and immediately I rushed out to read it. I mean, something tangible at last! Well, actually it wasn't really a read, but rather a very superficial skimming-over. There are good reviews of C++09 on the Web***, so I didn't actually want to read it in depth, but rather to get an overall impression of the changes: just how it all would feel like in C++0x: x < a.
And guess what? It was last year in November (sic!!!) when I read it and then wrote some things up :-(((. Somehow I'm too busy with my current project! Of course I'd like to read the proposal in depth and analyze it here thoroughly, but alas, it's not possible. So let's start with just few of my very personal impressions:
1. Ranges and initializers
What I perhaps liked best of the new features! Now I can write things like:
map<type-expr> m = {{}, {}, {}};
int a[] = {1};
vector<type-expr> v = { a, b, c };
SomeClass obj({ a, b, c, d });and that for any class I want! How is that done? You have to implement the
initializer_list constructor for your class! Wow, it feels just (like)
Groovy to me :-).
A great improvement over the oldskool tricks used to force initialization where it wasn't possible by the language definition!
A realated feature I liked are ranges:
for(int& x: array)
{
x = 0; // for example!
}
This is accomplished internally by a
Range<> class being internally instantiated with the array instance:
Range<type-expr>(array). It gives you a nice, scripting language like feeling when iterating; I mean, even Java's got it, and the
boost::FOREACH macro was in my personal opinion rather an ugly hack than anything else!
When talking about ranges: actually I was expecting that the ranges will be included for the STL algorithms, so we don't have to write the annoing:
find(v.begin(), v.end(), not_zero());
each time. I was quite positive that we'll going to have something like:
find(v, not_zero());
as an overload of the traditional STL signature using the new
Range<> class (there is a
boost::range library after all!), so I must say
I'm a bit disappointed here.
2. Some nice utilities I found
There were suprisingly large number of small interesting things to be discovered, like:
I liked these little things, and there is probably more like that to be discovered. It's refreshing to see that the smaller problems of day-to-day programming are addressed too!
3. Some expected things
As expected we've got the hash tables at last, as actually the whole
TR.1 stuff like regular expressions, type traits for templates, tuples, general binders and function objects, is in there too. Plus the move constructors and rvalue references.
Moreover the
auto keyword and the
lambda functions are there, so now we can write
auto iter = m.begin();
// and not
map<string,string>::const_iterator iter = m.begin();
at last! Just think how many keystrokes/copy and pastes it will save!
Speaking of lambdas - as I read it, there isn't one example of a lambda function in the draft! And moreover, in
"Chap. 14.3.1 Template type arguments" there's something missing: namely the old restictions about the non-global linkage of the template parameters! This means, I can write a functor in local scope and pass it to the STL algorithm like that:
void XXX::someFunc()
{
struct my_not_zero {
bool operator() (const X& p) { return p != 0; }
};
// use the local functor
find(v.begin(), v.end(), my_not_zero());
// OR use a lambda function:
find(v.begin(), v.end(), [] (const X& p) -> bool { return p != 0 });
}
I'd say, what was the reason for lambdas again (at least for me)? To be able write a functor which doesn't have to have global linkage! Are lambdas obsolete then? Well, both yes and no. Just look at the code example above, writing a local functor still requires quite a lot of plumbing, and a lambda expression is somehow more terse (we could even spare the return type of bool in our example!). IMHO both of them are not wholly satisfactory. Using a lambda library solution I could write it in a much more terse way:
// OR using my pocket lambda library:
find(v.begin(), v.end(), _$1 != 0 });
Another expected (and somehow dreaded) new thing are the
Concepts. I must say thery are everywhere in the standard library section, like in this new
std::list move constructor:
requires AllocatableElement<Alloc, T, T&&> list(list&& x);
I mean, now the standard library header files will get even less readable, but the compiler errors will be (hopefully) more so. So I'm in two minds about this feature: isn't it too much of the type system? What about the duck typing in templates? Are we giving it up? For me it was a very nice feature. I guess it won't come that bad, and the templates without Concepts will be working as before but are Concepts only for compiler support or are we supposed to use meta-typing everywhere?
The next expected thing, which however deserves its own section is:
4. Multithreading support
Sorry, I didn't read it yet... It's two whole chapters (29 and 30) ant they aren't exactly short.
But instead it started me thinkig: how was I writing multithreading applications before there was the C++ memory model defined? How on earth was this possible? Well, it was all vendor (i.e. compiler) specific. When a compiler supported the POSIX thread library (pthreads) for example, it would pose some memory fences around the pthread calls****. It would treat some pieces of code in a special way - just like in Java's String magic. The local static initializes would be automatically guarded by locks (Gnu compiler) or maybe not (Sun compiler). The volatile keyword would be given an extra visibility guarantee (Microsoft compiler). And I never initialized global static variables out of the multithreading part of the program, only in the main thread portion. An the best of it is, that all these techniques wasn't guaranteed to work****! But hey, the 1st Java memory model wa buggy too, wasn't it?
Now it's all supposed to be portable.
One thing which I did read up (however on the Web and not in the proposal itself), and what was a littel unexpected for me, is about the volatile keyword. The proposal didn't stengthen the volatile keyword in the way it's been done in Java or C#. I suppose that out of the reasons of backward compatibility with C's volatile remained only a compiler (dis)optimisation directive, while for the visibility guarantees between threads we are supposed to use the atomic<> library!
How will the old programs using volatile for visiblity between threads be running now? Are they broken? I suppose so, they probably must be rewritten using the atomic<> types.
5. Summing things up
My impression so far is, that there are many small things you wouldn't expect, and that they are fun! I was expecting the big new chunks of functionality to be added (and they were added indeed) to be the most impressive ones, but it's rather the small things which make the difference. Look at that code snippet in the new, cool layout style (which I picked up in this Ferbruary's issue of the MSDN Magazine) :
for_each(values.begin(), values.end(), [](int& value)
{
// now we can nest STL at last! (or can we???)
for_each(value.begin(), value.end, DoSomething);
});
I'd dare to say
that C++ seems to have put away its 90-ties image, as it allows to write programs more in style of the scripting languages than the old and venerable K&R C! I can only add
"at last" and
"Amen".---
* Thanks
Jens!
** Herb Sutter's announcement and some discussion with the inevitable C++ bashing:
http://herbsutter.wordpress.com/2008/10/28/september-2008-iso-c-standards-meeting-the-draft-has-landed-and-a-new-convener/, the Draft document itself is here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2798.pdf*** like the article in the Wikipedia, which I found to be surprisingly good:
http://en.wikipedia.org/wiki/C%2B%2B0x**** Hans Boehm:
"Threads cannot be implemented as a library" Technical Report HPL-2004-209, HP Laboratories Palo Alto, 2004,
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
