We have a new star in the heaven. This is the dawning of a new C++ Standard today, March 25, 2011.
The C++ Standard Committee in Madrid has approved the shipping of the C++0x Standard after nearly 12 years of work!
The x in C++0x is now potentially to be a 'b' in hexadecimal.
There are still possible stops in this process, but most of what remains will likely be procedural rather then technical.
What remains is final integration of all approved changes from this meeting, proof-reading, then a ballot by all the National Body on the resulting product, and then on approval of the ballot at a higher working group level, final entry into the ISO pipeline.
What comes out of the end of that pipeline (after several months) will be an approved Standard for public consumption, that you can purchase.
If there are any technical issues that remain, then it can still be stopped if the final integration leads to something that is a serious stop-ship.
I also must state that the Standard will not be free of all defect. Most of the issues we know about have been looked at and deemed either a corner case, or not serious enough for a stop-ship. This means we know there are places where we know there are errors, but they are not National Body Comments, nor serious enough to be a stop-ship. We can fix those with a TC
Like any software that ships, it will not be perfect. But it does reflect the best effort of a body of over 60 subject matter experts working very hard for the last 12 years (meeting 3 times a year since 2007). It also reflects the leadership of some very key and dedicated people.
Of the issues referenced in my last blog post:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/the_view_or_trip_report_from_the_mar_2011_c_standard_meeting24?lang=en
Here is how these controversial issues were disposed:
- Possible Removal of several features
- Rejected
- Complications with range_for found in Boost
- A good solution was found, please read N3271 when it comes out. Essentially, it specifies that the range-based for loop should look for member functions
begin() and end() first, and fall back to the current ADL-based behavior only when the type of the range does not contain either "begin" or "end". - Reconsider the impact of noexcept
- Accepted. As a result the committee spent a great deal of time going back over the previously accepted noexcept additions to the Std library, and reducing those cases. A new set of rules for when to add noexcept was published in N3279.
- Issue with a few keyword places with hiding and overriding rules
- N3272 removed the "hiding" feature and the "explicit" annotation on classes.
With respect to the Race condition on exception issue, there was a serious discussion on this with some admitting that we have a problem here (and some does not), but almost all agree that our hands are tied in that implementers cannot be asked to break backwards compatibility by fixing this one problem. There were some discussions that we must ask the user to use good rule guidelines to avoid this case. In many ways this may not be satisfactory and there may still be groups that want to work on this in the background. I will try to spend some time explaining this in a future post.
Fortunately, none of these became stop-ships.
Both my papers on atomics and threads were also accepted.
Many major vendors have already phased in C++0x features in various release of their compiler. Our xlC C++ compiler has been shipping C++0x releases since V10.1. Between all these compilers, most if not all of the features are accessible.
As an FYI, I will be speaking in Madrid, near Munich, and Boostcon 2011 shortly where we will have the first look at the completed Standard.