Oracle Blog

The Frankfurt C++ Meeting

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:

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:

(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:

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:

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 (on which, as you remember, I have been working the last weeks. Interestingly, Sylvain Pion (INRIA), is using the "parallel-mode" provided libstdc++-v3 and is also studying "transactional memory" (e.g., he is following the GCC effort in this area, focused on implementing the Intel ABI, and would like to test it for parallel insertions in the "STL" tree structures). With Alan Talbot we discussed the new simplified specifications for std::pair, and we commented that adjusting the new allocator model to not use Concepts, will not be a trivial task for Pablo Halpern. Too many to mention...

Hi Paolo,
I wonder what you think "the real underlying issue" described in N2855 was? It's not as though automatically generating move constructors can be used to make the problem go away.
BTW, for more on frankfurt: http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/

Hi Dave, and first thanks for your feedback, nice to see you here! Before any further discussion, can I ask you to provide a link to your Frankfurt presentation? I meant to do that in private but it looks like this is the proper place and time...

There's a link to the slideset at the top of http://cpp-next.com/archive/2009/10/exceptionally-moving/
Anyway, still very interested in your answer, particularly since we are /still/ working on the answer: https://svn.boost.org/svn/boost/sandbox/committee/rvalue_ref/N2983.html

Ah, great. And many thanks also for the link to the new N2983: I noticed some activity on the reflector but I didn't really follow it in detail. Anyway, since on Sunday I will fly to Santa Cruz, I suppose we'll meet again in person at the Meeting: over the next few days I'll try to catch up in order to meaningfully contribute to the discussion... and I'll keep the blog updated.