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 = {{}, {}, {}};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!
int a[] = {1};
vector<type-expr> v = { a, b, c };
SomeClass obj({ a, b, c, d });
A realated feature I liked are ranges:
for(int& x: array)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!
{
x = 0; // for example!
}
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:
- error support: error_code, system_error - well, I can definitely use some of it!
- compile time (i.e. template) rational arithmetic - suprise! BTW do we really need it?
- clock and time_point classes - useful!
- stoi: string to int conversion - a suprise!, so don't we take the road of lexical_cast<> as I was expecting all the time?
- alignment control - at last I can say what the aligment is and not the machine! Will then the machines revolt?
- unique_ptr - just what we need most often, or auto_ptr fixed!
- addressof - even if the actual & operator is overloaded!
- reference_closure as Callable - what was that again??? But I wrote it up in my original notes, so it must be something funny!
- delegating constructors - we can reuse one constructor in another one, like in this example from the draft document:
struct C {
C(int){} // 1: non-delegating constructor
C(): C(42){} // 2: delegates to 1 - nullptr as a keyword - no more the annoing (XXX*)0 casts!
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();at last! Just think how many keystrokes/copy and pastes it will save!
// and not
map<string,string>::const_iterator iter = m.begin();
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()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:
{
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 });
}
// OR using my pocket lambda library: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:
find(v.begin(), v.end(), _$1 != 0 });
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)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".
{
// now we can nest STL at last! (or can we???)
for_each(value.begin(), value.end, DoSomething);
});
---
* 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
