The View (or trip report) from the Nov 2010 C++ Standard meeting
Michael_Wong 120000M1EH Visits (6504)
Our mission, though somewhat less grand then the fate of cosmology, was to decide what to do about several controversial matters which were well known and well summarized in Anthony Williams blog:
Recall in my last report that we hardly have any controversy in the August Rapperswil meeting. While that was not intentional, it merely reflected the process of National Body Comments in response to the Final Committee Draft. At Rapperswil, our first chance of seeing the NB comments meant we were very busy with triaging the comments, placing them immediately into specific categories of response types, sending them to the proper working groups, but also addressing basic ones, or ones that were obvious or non-controversial. Here is a breakdown of what was done in the August meeting.
In total, 519 comments were received. To date, 257 have been accepted as proposed, 18 have been accepted with modifications, 84 have been rejected, and 140 remain to be addressed. The detailed breakdown:
CWG is Core Working Group. LWG is Library Working Group. The tag editor means the comment was editorial and can be addresed by the project editor, Pete Becker.
A summary of the NB comment status can be found in this document:
There is also the believe that if we are to ratify a Standard in March 2011, then we need to deal with all major controversy in this meeting, whether we were near the Windy City or not politically. Some might even be cynical, and see this as the last opportunity to push through any last minute features. The reality as always is more complex.
What is happening to the C++ Standard is very similar to software delivery. The only difference is that we deliver a document of words, instead of bits and bytes. Well, at the most fundamental level, it is all bits and bytes. In some waterfall software development cycle, there is an integration stage whereby all the new features are brought together for the first time to see how they work together, and with legacy code. It is in this integration stage that the C++ Standard is grinding through. Just as in software delivery, there are always bugs that are found during this stage which requires serious deliberation.
If the problem is serious or pervasive, or hard to fix, then we might pull it out. While I am not saying that Concepts fall in this category and had these issues, it was one of the candidate that was pulled out. Some would argue that rvalue reference also is one of those, but in some cases, you might find that removing something can be more problematic then leaving something in surrounded by a scaffold of fixes. We will describe some of that scaffolding next.
Some bugs may be found to affect legacy code negatively, and may require a difficult choice of disabling from being available in the default mode, or reducing its wide ranging affect on legacy code through a narrowing of its effects. Again, not saying this is the problem, but Implicit Move Constructors were ones that had potential to break legacy C++ code, and it was decided that its effect should be narrowed, although many also argue for it to be pulled from the default mode by disabling implicit move constructor and move assignment operator generation, and let the user write them manually or use "=default" to request the generated version. Specifically, we will tighten the conditions for generating implicit moves. This revises the rules for when to generate a move constructor or move assignment operator so that if a user declares any of the standard member functions, the move destructor or move assignment operator is not generated. (That's only an approximation; see the paper for the precise rules.) That avoids implicit generation of move functions in some cases where that could break exception guarantees in existing code. The rules for the generated copy constructor and copy assignment operator are changed to mirror the rules for the move case by making the implicit generation deprecated in some cases. That avoids changing the semantics of existing code but allows compilers to start warning that classes should be changed to the new model where if you declare any of the standard special members you should not expect the others to be generated for you.
Other bugs may be the result of an unanticipated interaction between a new feature and existing state which offers an opportunity for lightening the user's burden. The implicit declaration of noexcept(true) in destructors and deletes offers one such opportunity which while it sounds like good software engineering, have the potential now to break some user code on the edge. However, its soundness overrides most concerns and this was accepted. On destructors with no explicit exception specification, the exception specification that would have been determined for a generated destructor is used. That is a refinement of the proposal of last time that all destructors simply get
Another class of bug is the interoperability of your code with other software. Atomics between C and C++ became just such a poster child as it became uncertain whether you could write a line of C atomics and it would mean the same thing or even compile in the same way in C++. C1x which will go to its first Committee draft soon, has chosen to use its own productive syntax (using keyword _Atomic). The application has some issues in compatibility in that not all atomic operations, mutexes are compatible between C and C++. This makes any attempt to paper over the differences inside a common header using a macro which redirects to C syntax if it is a C file, and redirects to a C++ syntax if it is a C++ file, problematic. In the end, it was decided to not assume any compatibility, and leave in a state similar to C++'s Complex classes and C's _Complex type, until we know for sure how C will approach it.
Finally, it is possible the existence of new features mean that your code might now require even more user intervention to actually take advantage of it. Such could be the example of implicitly deduced noexcept specifications, which could be onerous to write. But in this case the creation of a new feature (to deduce the noexcept specification) at this late stage was deemed to be more of a problem then what it solved. So the committee chose not to move ahead, although there is reasonable expectation that the feature would be revived in future ratification.
All the the solutions are needed to ensure that the Standard features works well with each other and with legacy code. This kind of fixes at the integration stage is common in software delivery and is no different here in the late stages of C++ Standard ratification. But it is a good idea to look through and understand which problems are the most serious and require immediate action, which feature need to be pulled out to give it more baked in time, or which needs to be enhanced, or which needs to be left alone because we all agree to accept the risk.
These are actions and risks all software developers, release managers, and large projects are familiar with. In the end, we think the user will get the best compromise, although you may not agree with this. Some have asked if the number of defects, churns and fixes means we should not ship, or delay the shipping of this standard. Let me say that the committee plans to address all NB comments as they did in the last Committee draft and this resulted in a significantly improved specification. This will happen with the FCD before it goes to the Final Draft International Standard (FDIS) in March 2011. At that time, the Standard will still have defects, and as long as they are not major and pervasive, we can move forward with dealing with them. Please comment if you feel otherwise, but look forward to the true birth of the new C++ Standard in 2011 if all goes well.