The Frankfurt C++ Meeting
Hi everyone,
from July 13th to July 18th I attended the Meeting taking place in Frankfurt, Germany. Due to the European venue and probably also the general economic conjuncture, the total number of attendees was rather low, around 50 people overall.
The most dramatic event of the week took place on Monday, when Bjarne Stroustrup gave a presentation titled "Concept alternatives", summarizing all the various options for Concepts in the next standard, in the light of the recent discussions and concerns raised in the ISO reflector and elsewhere. For a lightweight introduction, with references, I would suggest:
http://www.ddj.com/cpp/218600111
or, directly, rather readable overall:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2906.pdf
In short, over the last months, some people - first Howard Hinnant, and then Bjarne himself and then many other - began doubting that the current specifications of the Concepts features, as already voted in the Draft, were optimal from the usability point of view, that is from the point of view of the mythical "Joe Coder". In particular explicit concepts, thus the need for a large number of Concept maps, appeared pervasive in such central features of the library like the iterator hierarchy. Fixing those problems seems in principle possible (see Bjarne' paper above for some interesting sketches) but requires an highly-non-trivial redesign of large parts of the core specifications, not something that can be done at a late stage of the development toward the next Standard.
After much additional discussion, eventually July 13th the attendees voted to "decouple" Concepts from the Standard, thus effectively removing everything having to do with Concepts from it, and try this way to honor the schedule of a Standard ready by 2011 if not before 2010 as initially hoped. Note this move will require by itself a lot of work, because the Draft must be reverted to the pre-Concepts state, many fixes to DRs included, which were rather easy thanks to Concepts, which must be now re-opened and attacked in a case by case way.
After that kind of shock, the rest of the week proceeded in relatively dull way, with separate working groups, as usual (core, evolution, library) processing DRs, in a rather aggressive way, much more aggressive than other times, in my experience, in particular vs issues to be closed as NAD / Future (2-3 issues of mine also fall in that category, including DR 585 and DR 760) and many issues corresponding to comments from national bodies (which *must* be addressed to release the Standard). That kind of attitude is necessary, if we want to get the new Standard out of the door.
It's probably worth mentioning, however, a rather serious problems involving some uses of rvalue references (i.e., the new && syntax) vs exception safety, see this paper for an introduction:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html
(at the meeting, Dave Abrahams gave a nice general presentation on Thursday, which is not publicly available yet, I'll try to get ahold of it). As you can see, the problem is pretty serious, essentially implies that it's very hard achieve exception safety in very common uses of mixes of moves and copies. Luckily, a fix is possible, and elegant, along the lines explained by Bjarne in:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2904.pdf
which, as you can see, attacks the real underlying issue with automatically generated move and copy constructors. The detailed wording for this solution will be scrutinized by the Evolution working group at the next meeting, but it looks like we have a neat way forward.
One remaining discussion I want to mention is the one turning around the following paper, again presented by Bjarne at the meeting:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf
where it's explained that the design pursued by GCC (libstdc++-v3) as regards the iterators of the standard container is the best one, performance-wise and from other more theoretical points of view, to be preferred to the one used by, e.g., Dinkumware (thus Microsoft). At the meeting, people decided not to enforce for C++1x the design used by GCC thus forcing an unexpected ABI-break in this area, but the moral "winner" is clear.
What else... During the meeting, as usual I have been able to approach many colleagues and share experiences about implementing various parts of the library and of the core C++1x facilities too, i.e, with Jason Merrill (Red Hat) we discussed a few g++ issues at the interface with the library resolved during the meeting. To Walter Brown (Fermilab) I pointed out a few minor issues, hopefully editorial, in the current specifications for
For now, thanks for the attention!
Paolo.
