C/C++ and Fortran

 View Only

The view (or trip report) from the Aug 2011 C++ Standard Meeting at Blomington IN

By Archive User posted Wed August 24, 2011 03:53 PM


Originally posted by: Michael_Wong

This Standard meeting is earlier then the usual C++ Standard meeting to accommodate the period of time after the approval of the C++0x draft when National Body balloting has to be done to approve the draft and ratify it. The new C++0x Standard has been ratified and will be called C++11. As an additional note, the C standard is also undergoing ratification vote and will also likely be approved.
So there is now a quiet period when we cannot issue new papers. As it happens, the defect reports for core language and  library are also issued as papers so there can be no new revision there either, by ISO rules. However, the work of defect fixing continues and this was the main task at this meeting hosted generously by Indiana University in Bloomington, IN. Because we are in this quiet period, there was no Evolution Committee meeting so no new proposals were heard, reviewed or voted. Nothing.
There were some sneak peaks at some possible new proposals that will be forthcoming, but of most interest to all is where is C++11 going now after all this work? Will they take a breather, like they did after C++98 and let implementation catchup? No, that was probably what lead to a 11 year wait between Standards.  However, implementations do need time to catch-up. Most C++ compilers, like us have started C++0x implementations. We have already issued three release xlC++ V9, V10, V11.1 (for AIX, and Linux) and z/OS V1R11, V1R12, and V1R13.  In another post, I will describe in more details what C++0x features we already support.
However, what I want to talk about is the Future  of C++ which was what was the major discussion point at the C++ Standard meeting plenary. It is what was on everyone's mind. Herb Sutter presented a plan which was hotly discussed. He proposed that we adopt a bus development model where a Std bus will leave every 3 years and pick up whatever work has been approved in the first 1. 5 years. This will allow a new C++ Standard every 3 years. In reality, it  might be longer then 3 year, maybe 5, but not the 11 years that it has taken since C++98.
One interesting discussion on the Future of C++ is how many would like us to invent new stuff, or wait a year for implementation to catchup, or even wait a few more years. Which of these would you prefer?
Specifically, we would take 3 meetings to review new proposals, and then take the subsequent 3 meetings to massage those proposals that are approved into shape for Standard inclusions. Since the C++ Standard meets twice a year usually co-located with C, this means an estimated total of 3 years.

What this means is that we will be inviting new proposals in the next C++ Standard meeting in Feb 5-9, 2012. There are already a number of proposals for concurrency, which could include Cilk++,  C++ AMP, TBB, ArBB, PPL, and my personal interest, Transactional Memory. Library already has a number of proposals, including what was left off the table in the Kona Compromise of 2006, where we decided to drop a number of advanced concurrency abstractions due to time constraint of C++0x. One such example proposal that could now be considered include a proposal by Howard Hinnant to add functionality to support the the well-known multiple-readers / single-writer locking pattern.This will add unique_lock<Mutex>  that allow explicit try and timed conversions from shared_lock and upgrade_lock. In addition, there will be a new header: <shared_mutex>, containing lock conversions between shared_mutex, exclusive_mutex, and upgradable_mutex. The original Kona proposal can be consulted for more details as it is largely unchanged: N2094. I also presented the result of a joint effort at harmonizing C and C++ atomics which was presented to the C committee with some of the proposals accepted: N1560
Library is already inviting new proposals and is looking at date/time, permutations, shared_lock, asio, and  primitive datasets with xsl.
What we have learned from previous experience is that one of the best way to ensure high-quality and low risk is to do things through a Technical Report which are non-normative but allow us to test drive new proposals. TR1 contain 14 libraries and gave us implementation experience before 13 of the 14 libraries were accepted into C++11.  Using a similar model, we can have Library TRs and Language TRs.
There were some disagreement as to how to do this given implementations will be far behind already with the C++11 Standard. This is probably unavoidable. There was also concern about creeping proposals trying to make it in the last minute of the 3 year period but some felt that if we firmly cutoff at the end of the proposal period of 1.5 years, that will be a clear message that no new proposals can creep in. Furthermore, if the Std bus will leave on a more regular schedule, there will be fewer need to jam in last minute proposals. 
Anyone can submit proposals, not just committee members. Unofficial voting, or straw votes are often conducted to poll for feedback and reactions and anyone and any number of people can participate in these straw polls which are ongoing during discussion phases. However, when it comes to final official voting conducted during plenary sessions, only committee members in good standing can vote. The key to having proposals accepted, while not mandatory is a sustaining presence on the committee to address concerns and issues, iterating on the proposals until it is accepted through Evolution, then either Core or Library, or even both. The sustaining presence could be the author or someone who regularly attends committee meetings who can champion the proposal. Subgroups are allowed to make progress between meetings. Another non-mandatory but unspoken important step is of course prior implementation experience on the proposed new feature. In C++11, almost all features were implemented by some vendor with the exception of at most 2-3 minor features that were deemed too simple or risk-free to require early implementation.
Hopefully, this gives everyone a view of what it takes to have a C++ feature approved into a Standard.
As an aside, I will be at the Karlsruhe Institute of Technology on Sept 6 to open the new semester by giving a lecture on the Future of C++.