No new Standard before 2017. That is the word from the C++ Standard meeting in Feb 2012, the first meeting since the ratification of C++11 after the Indiana meeting in August 2011. It must be the location, because it had over 60 attendees. We seem to have one of these every five years courtesy of PlumHall, although this one
was paid for by Bloomberg. Thank you, John and Tom.
The first and last thing on everyone's mind was when will the next Standard be? Will it be another 10 years? As this meeting included the reopening of the Evolution Subgroup, this question had to be dealt with before we even look at any of the proposals. Herb Sutter guided the group towards a bus/train model where we will continue work, and pick up whatever is ready. There were massive uncertainty as to when that ship would leave, with anywhere from 2013-2022 being mentioned. After all the votes were done, the crowd settled on 2017, with a 2022 follow-on standard, every five years. Cutoff for new proposals will be in late 2014.
Some had hoped for a shorter publication period of may be three years, but in retrospect I find five years to be almost appropriate.
Let me say why. I think it takes time for a new Standard to stabilize in terms of time
it takes for writers to update the books, for new programming style to be discovered and nurtured, and for implementers to fully implement the last Standard, while fixing all the things that
needed fixing along the way.
If I recall the 1998 C++ Standard, it took some time for that C++ to be fully used by industry.
Virtual inheritance was not used extensively for nearly three years. Five years later exception became more extensively used,
and seven years later the full power of templates was discovered through extensive research. To this date, many compilers have not repaired all the
defects in their template implementations, as witness the frantically wild pass and fail rates of Boost test suites.
This shows that it takes time for a new Standard to evolve to be used by the community. Today, that evolution will no doubt occur much faster with the help of the internet. Indeed, what took 14 years in the last decade may only take 5 this decade.
But it does take time for all this to happen and a five year time space, I would argue is completely appropriate.
Anything earlier will not encourage users to start immediately using the features, and anything longer will risk losing competitive position in the rapidly evolving world of programming models.
The other major discussion point was with respect to the need for more C++ libraries.
A while back when we were doing C++11, Bjarne had made a plea for far more libraries for C++11. He viewed this as one of C++' s greatest weakness. That did not really come true. Now C++11 is still behind in the number of libraries it supplies when compared to Java, or some commercial implementations. For the future, a further plea was made to develop a public organization to hold a public Open Source Library called Portable C++ Library (PCL) that will feed into standardization. He envisioned this library will tab contributions from releases from many companies, including Boost, but package it in a uniform way, using consistent types and styles while being shipped by all major vendors. More about this in future but here is a list of current proposals Library Working Group is working on and their rules.
No official votes were done at this meeting, not even straw polls for the Evolution group. Core and Library group processed over 120 defects. which is their normal amount. A number of issues were under discussion in Core which could have impact:
- Core 1438: restricting access of invalid pointers
- Core 739: require bitfield type of int be signed
- Core 1457: left shifting a 1 into the sign bit is now implementation defined and not undefined behaviour
The Evolution subgroup separated potential features into 4 bins:
- cleanup small features for C++17
- stretch features for C++17
- features for C+22
- not considered at this time
We also designed a list of EWG criteria. This is still early but can act as a guideline. In the remainder sessions, EWG started to look at a number of proposals.
We started off with advanced abstractions of concurrency. Intel started driving in Cilk ++ syntax and semantics to support task parallelization, as well as data parallelism through vectorization SIMD syntax similar to openMP with a morning presentation based on n3361.
They are proposing 5 things:
- parallel tasks (3 Cilk keywords) with tasks, and load balancing
- HyperObjects: mitigate data races on non-local variables
- Array Notation: data parallel array operations targeting GPUs, and SIMD
- Elemental Functions: data-parallel function mapping
- SIMD annotation: vectorization annotation for loops
The general comment from the committee is that we need to compare what we already have in C++11 (Async, futures, promises) with this proposal, as well as understand what other industry prior arts tells us including Microsoft's C++AMP and PPL.
Next we also looked at Microsoft's async and resumable function proposals as well as a coalition of companies' design on Transactional Memory. The proposal that I worked on was the Transactional Memory proposal. We have been working on this common-vendor proposal for nearly 3 years now and in fact just issued Version 1.1 publicly. This proposal adds a number of changes which I will describe in a separate post. But in the mean time, we wish to present some of the work for inclusion in a future C++ Standard as a Technical Report. Our talk included elements of the common problems our group has solved, as well as partial experimental implementations from Intel, IBM, Oracle and GNU. However, the committee was more interested in experimental results outlining what particular benefits TM conveys specifically with regards to
performance and ease of programming. This data we have in abundance, but we need to collate this together in a coherent way. We hope to present this data in the May summit. There were also a number of proposals from Google outlining improvements and fixes to concurrency.
In general, all the advanced concurrency proposals while interesting and welcomed, were all asked to come back with answer to some serious questions and issues.To that end, there will be a special summit in Redmond, lead by Hans Borhm in May 2012 to discuss these alternatives. In this Summit meeting, all the concurrency would be up for discussion as well as a survey of the state of the art of the industry. This is similar to the early days of 2005 when we first started discussing adding basic parallel abstractions and memory model to C++. We also had a similar meeting where we looked at all the issues that were potentially problematic. There would be no decision at this meeting, but rather it is an attempt to flesh out a reasonable view of the issues and use that as a way of moving forward. This May Summit would be the same. Many experts, and senior engineers from MS, Intel, IBM, Nvidia, AMD, Oracle, HP, GOOGLE, as well as others would be present to discuss their experience with advanced parallel abstractions. We might even invite representatives from other ISO languages as everyone must be facing the same multicore programming model issue.
In other non-parallel related proposals, we started a serious look at reflection, looking at rich pointers. Some have argued whether runtime reflection can be emulated in compile time, thus costing less in implementation and performance. The rich pointer proposal is one such puzzle piece, as are other reviewed such as n3326, which covers sequential access to data members and base sub objects which seems to be a good start on reflection as well
While not a proposal, an over 100 page progress report on Concepts was reviewed. Quite a lot has happened with concepts.
University of Indiana, Texas A&M university, A9, and Alex Stepanov has gotten together to look at simplifying Concepts (which were removed in Frankfurt due to serious issues found at that time). Their effort showcases a work in progress where a few controversial issues have been greatly simplified. They started work based on Alex Stepanov's recent book on Elements of Programming. The aim was to make concrete Concepts only based on mathematically sound principles. This means there are now far fewer concepts, and no concept maps. Many Concepts would embody a collection of ideas that were mathematically linked. In so doing, they have reduced the frightful proliferation of over 100 concepts that were introduced until Concept was removed. This new proposal can have almost all the Concepts fit on a single slide. This looks very promising.
We also looked at static_if which seems to interact with Concepts and act as a kind of light-weight Concepts. Some even call it a Concepts killer because of its similarity or interaction with the Concepts requirement clause. I am not so sure about that, and Bjarne promises to have a serious look at this for the next meeting. Static_if was started in D but was also independently proposed by Walter Brown of Fermi Lab, it outlines the idea of deciding code to compile using a compile-time test. This is also a form of compile-time reflection as well. The controversial point is what to do with the part of the code that is not compiled. Is it discarded or compiled only to tokens? There was no consensus on this. I have to agree that the usecases are compelling, but the interaction with Concepts shows a possible structure problem in the design, thanks to Robert Klarer's feedback to me and others on the reflector who pointed this out. The papers also shows no implementation description, leaving it unclear whether 2 phased name lookup is applied or not. The authors promises to come back with good answers to these issues.
Module was once again highlighted by Daveed Vandevoorde. This work was stopped early in C++11 due to resource issues but has now started again.
One of the main motivation is that include files causes the C++'s constant recompilation problem, where any changes in an include, must now lead to recompilation of all files that depend on the include, and any files embedded within the include.
By some estimate, 99.9 % of some sources live in includes leading to maintenance and compile-time nightmare.
Modules offer the ability to shorten that compile time by keeping somethings in a binary form.
One of the key issues is the interaction with Macros, and how to transition to Modules. A few people showed a way of migrating, by pretending all include headers are in fact module imports. This would give us the immediate feature of supporting modules but what is to be done with macros? This was an issue of much discussion with no clear preference.
A tiny proposal, but no less important was the idea of digit adding separator support for C++ numbers. It uses _ as separators. Many have wished for digit separator for a long time, but it is one of those nice to have items.
They interact with user defined literals, which in my very biased opinion (as the UDL author ) is a more important feature, in that a UDL suffix which is _f can be banned as a result of this proposal.
This was deem too damaging to UDL as many things in scientific computations (e.g. feet) could start with f and banning _f would kill them.
We decided more investigation needs to be done. One idea started from Daveed which I support is the use of ' as a separator.
In fact, I claim this is more natural then _ in many part of the world where use of apostrophe as separator is already common.
The use of _ as separator is our invention, and , or : or even space is not possible for various grammatical reasons. So why not use something which many Europeans already use which is apostrophe. C++ is not just an English Standard but a world-wide standard and should be respected as such.
As with all proposals at this stage, Bjarne mandated that no straw poll be done at this meeting and we fulfilled that mandate. This seems to be the right decision. All these proposals are interesting, have good aspects, but also show some serious issues that require continuous work. They were all sent back with the no promises as is the usual case, but definite encouragement to return with modifications.
With respect to parallelism, so many advanced abstractions were proposed that we have decided it is time to
have a Summit of parallel programming experts. Just as we did in the early days of concurrency where
we gathered experts to discuss the issues to support basic abstractions of concurrency, we decided to follow the same route.
While no decisions can be made at these meetings, our goal is to examine the many ideas of advanced parallelism from different areas, as well as their problems. I plan to attend this meeting hosted by MS in May, and hope to host one in Toronto if there is need for a following discussion. In this meeting, we will discuss the implementations and usage experience of Cilk, TBB, ArrBB, PPL, TM, OpenMP and many others.
To support this, C++ has started four Study groups. To quote verbatim from the minutes:
SG1: Concurrency and Parallelism (Hans Boehm) SG2: Modules (Doug Gregor) SG3: File System (Beman Dawes) SG4: Networking (Kyle Kloepper)An SG is not a formal project, and so ISO does not formally appoint an Editor. However, some SGs will be working on a document, and those SGs should have someone who acts as editor to maintain the working draft of that document, and publish each draft revision as an N-numbered paper. The SG can approve changes to its own working draft, but the understanding is that the final product will be a submission to a full WG21 meeting for further processing.
There is no problem with work in between official meetings and it looks like there definitely will as Concurrency plans to have the summit in Redmond, WA as discussed earlier. The most likely tentative date seems to be May 7-11 week at this point. I will keep you posted as more information become available.