Originally posted by: Michael_Wong
The C++ Standard meeting this week in Madrid will try to ship the Final Draft International Standard. This will become the next C++ Standard and replace the 2003 (or 1998) C++ Standard with about 140 features (spread between language and library), and 600 defect fixes to the core language.
Make no mistake, this could be a historic week, perhaps not with the same impact as IBM's Watson beating human Champions on Jeopardy, but still worth mentioning for one of the top major general purpose language which has not been changed for the past 11 years.
We had dealt with a number of controversial issues in the Fermi lab meeting, where it was one of the most controversial meeting.
In this meeting, Anthony Williams has described very well one of the key issue which has to do with race condition on an exception because they do not make copies in some implementations:
Other issues that could be concerns are:
- Possible Removal of several features
- Complications with range_for found in Boost
- Reconsider the impact of noexcept
- Issue with a few keyword places with hiding and overriding rules
Of these the potentially most serious will be the Race condition issue and the noexcept issue.
I have collaborated with Anthony on a solution for the Race condition on exception, which requires a potential change in the C++ABI, as well as other ABIs. This is because existing ABIs usually do not copy their exceptions when thrown, and this will be a problem when they are referenced from multiple threads, especially when they are modified which can lead to race conditions. Opinions vary on the prevalence of this case and it is on this that most will probably make their choice. Even so, I recognize there is serious opposition from some vendors because of backwards compatibility issues.
Noexcept, which was introduced recently as a solution for move construction, has been liberally sprinkled into the Std since its inception. Bloomberg has brought forward questions as to whether this is wise in view of testing, where the addition of this noexcept contract precludes test harness from using exceptions to identify cases where a precondition has been violated. So the proposal is asking for us to reduce the cases where noexcept is used in the library. This seems to be a reasonable proposal.
If any of these issues become deadlock or stop-ships, it could lead to delays in the ratification of the C++ 0x Standard.
I have two papers submitted which I will be working for approval:
I hope this give people a few ideas about this historic moment and watch for posts that indicate this Standard has shipped.