Originally posted by: Michael_Wong
Many people probably don't know this, but I got this authoritative statement from the Father of C++, Bjarne Stroustrup himself just before the Oct 15-19, Portland C++ Standard meeting. We tried to get together for a drink on that Sunday night to celebrate the C++ Birthday, but some of us could not arrive in time. We did have a drink the next night for a somehat different reason. Its a reason that will become apparent in a few days ..
So Happy belated Birthday, C++! Believe it or not C++ is technically 27 years old, depending on how you count the birthday. It is 27 years old, if you count it as the day that Stroustrup’s
original C++ book was published on Oct 14, 1985 based on this picture.
Of course the inception of the idea and its long gestation period is probably much further back in time. Based on my personal conversation with Bjarne while at Portland, and Stroutrup’s book on Programming: Principles and Practice Using C++, Chapter 22 on Ideals, C++ had its genesis from Simula 67 and Classic C as early as 1978. I highly recommend reading this book for its education value as it was trained on several undergraduate freshmen courses at Texas A & M. I personally use it with Bjarne's permission in my Advanced C++ course.
Onto the C++ Standard meeting last week held in beautiful and wild Portland, Oregon. This is not the first post C++11 meeting, we had one in
Kona in Feb. It is one of the first to really get down to work on C++17. However, C++17 may not even be the next immediate Standard.
I know I said that there would be no new Standard until 2017 in the previous
Blog post. But that has changed again.
There is now interest in putting out C++14, which is an intermediate Standard to address C++11 annoyances and a bug fix release.
Many of the proposals that were put forward as strawman conceptual ideas in Kona now has real substance behind them, at least to varying degree.
An interesting phenomenon is that we now have the creation of numerous Study Groups. There are focus groups that look at large Evolution proposals. It relieves the Evolution Working Group from having to deal with large features that block smaller features from being processed, but also allows a concentration of experts to work on a feature for delivery at a time of the group’s choosing. Coming into this meeting, we had six official study groups. Some of this occurred in a special Advanced Concurrency summit that happened in May 2011 (which I attended but has been too busy to report on; In fact so much has happened since my last blog that I have been unable to keep up with the blog due to the multiple meetings and events that has occurred, such as the OpenMP Meeting in Rome, my talks at the Advanced Developers C++ Conference in Munich, and at C++Now (formerly BoostCon) 2012, and a recent
OpenMP meeting just this week which I just finished before putting pen to blog today; none of which I have had time to report on since taking up the role of CEO of OpenMP. I will try to do better.).
In fact, in this special summit, I was nominated as chair of SG5 Transactional Memory, after presenting some reasonably convincing evidence as to why Transactional Memory should be considered for Standardization (but first as a Technical Specification). More titles and job responsibility, but we do live in interesting times, so goes the Chinese proverb.
So here are the additional study Groups beyond the original Concurrency SG:
- SG1: Concurrency and Parallelism Study Group
- SG2: Modules Study Group
- SG3: File System Study Group
- SG4: Networking Study Group
- SG5: Transactional Memory
- SG6: Numerics
During the meeting, it seems likely to increase that to eleven. Additional Study groups were proposed for Range, Reflection, Concept, as well as others. By comparison, C++11 had only one study group and that was Concurrency, out of which came all the designs for atomics, memory model, basic thread support, as well as async, packaged tasks, and futures.
A large number of Study Groups could mean that there is the potential for collision as all these Study Groups heads towards submitting work destined for the Standard. This could create a serious traffic jam.
To further put this into context, Bjarne believes that for C++17, we only have resource for 1 major feature, 2 medium features, and a dozen minor features. It is not clear what that one major feature will be. Modules? Concepts? Advanced Parallel C++? Transactional Memory? What will you want as the major feature for C++17?
Procedurally, in core we had about 100 issues, and moved 40 issues to ready status for the Bristol meeting.
Some changes of interest include the following :
1. Specify in the next meeting that only an integer literal with value 0 will be considered a null pointer constant. Keeping the C++03 definition that allowed any zero-valued integral constant expression to be interpreted as a null pointer constant would mean that a use of a value-dependent constant in template could be represented sometimes as a null pointer and sometimes not. This problem was exacerbated by the introduction of C++11 generalized constant expression.
2. Const qualified variable that is not explicitly given external linkage receives internal linkage. As a drive-by shooting, the core group also clarified that const volatile variable is not a POD , so now only non-volatile const variable will be implicitly given internal linkage.
In Library, a number of papers were moved forward to further support constexpr in libraries such as complex, chrono, containers, and utilities. A few other papers were reviewed with the eye of being part of C++14. The one paper I collaborated on was a proposal to fully ratify the currently non-normative
Decimal Floating Point proposal. This was reviewed with positive support for ratification through one of the Study Groups (6: Numerics). The other papers I submitted were on Transactional Memory which I will talk about in some length.
For Evolution, we added a Tiny Issues list to address annoyance and things that can make life simpler for programmers. If you have some annoyance in C++11, please let me know and I will email the keeper of that list, Ville Voutilainen, the Finnish Head of Delegation.
Evolution is specifically looking at things that need to make C++14. So the focus was on small features and annoyances that can be fixed. They were able to process a large number of issues that arose out of C++11 interaction that we are beginning to find from early usage and implementation experience, precisely because the larger features were moved to Study Groups which I mentioned above.
Starting with a few smaller proposals, there was a proposal to make Return type deductions for normal functions similar to lambdas return type deduction whenever there is one single executable return statement which makes it clear what the return type would be. This was accepted.
We also approved a proposal to fix Lambda correctness and usability issues enabling the capture of this which was a deliberate design decision. Another surprising aspect of lambdas is that they enable implicit const capture because it was felt that this was required for their safe use in async. This means that you need to deliberately make it volatile and that is often an odd thing for people to do when compared with normal functions. This was not well received and was rejected probably for the async safety reason.
There was a discussion on the problem of over-aligned types for dynamic memory allocation. This was reported to me by Kim Barrett at C++Now (formerly BoostCon) 2012. There was consensus that the problem should be solved, but the method of solution was controversial. One could add new overloads for new, and there was lack of consensus for handling offsets.
We discussed polymorphic lambdas. C++11's lambdas are monomorphic meaning they always require a type placeholder for the lambda parameters. A polymorphic lambda would not require such and would likely be implemented in compilers as an unnamed template class/struct functor. This would allow for a far more flexible lambda which has been shown to be useful in other languages, which is really another name for a local function. But there were 2 issues. Do we like generic lambdas, and do we know how to make them so we don’t get into trouble with parsing? Many have used them in books or other languages. Jarko Jarvi had done analysis and felt no problems. The two main popular variants are:
[](I,j) j<i
[](auto I, auto j){return j<I;} //you can also deduce one and not the other
The first is a complete minimal representation. The requirement indicate that auto should be compulsory, An alternate syntax adds <class T> in between the [] and () which was mildly popular but not as much as using auto as a placeholder. Some supported omitted return. There was also support for pointer-to-pointer conversion. This design was not ready for core language as yet.
C++ 11 Lambdas have other problems. They can be captured by value, by reference, but there is no support for move capture. This prevents us for using stringstreams or unique_ptr with a lambda. There are some workarounds for this, such as using bind with a const reference parameter. We have idioms for using move, and idioms for using lambdas, and they don't really fit together nicely. There was generally consensus that this is a problem that needs to be addressed.
N3401 discussed the move constructor suppression problem. For suppression of move constructors, we want uniformity. This means treating implicitly defaulted moves the same as explicitly default moves. Howard Hinnant went even further, stating that if an initialization is well-formed, then the implicitly generated move constructor should not be suppressed.
Voutilainen did some nice analysis of the options and summarized the four choices:
- Status quo, implicit: suppress, explicit: delete
- Core 1402, implicit: suppress, explicit:ok
- Merrll, implicit:suppress, explicit: suppress
- Hinnant, implicit: ok, explicit: ok (basic guarantee)
We basically want to treat implicitly defaulted moves the same as explicitly default moves and currently this is not the case. So the last case was chosen.
We almost have found a solution for a safe digit separation. The usual _ has a problem in that it clashes with User-defined literals suffixes that have hexadecimal digits. A proposal to retain the underscore that most find natural as a digit separator but add an optional space for hex such as 0xdead_beef aa would solve the problem. But at the Plenary, Chandler Carruth felt that this proposal would make it incompatible with Objective C. And while we have no specific linkage with Objective C, there is a substantial population that mixes C++ with Objective C code, and it would not be good to break this set of users. We must go back to the drawing board on this one. In the end, if this problem turns out to be too intractable, and it is beginning to look that way, it does not look like there was a huge overwhelming support for the need to solve this problem.
There are actually far more issues then what I can comfortably cover here. But I endeavor to try to expose some of my favorite topics, some of which I will use as an upcoming keynote for a C
++ Users Group Conference in Dusseldorf on Nov 9/10:
I am definitely looking forward to seeing some old and new C++ friends there, having enjoyed traveling to Germany many times this year. But before that, I will give another keynote on Nov 6 on What is wrong with the languages today
here at CASCON 2012. And after that, I will have a number of keynote addresses as OpenMP CEO at SuperComputing 12 where we anticipate exciting release news on the next OpenMP 4.0 Specification.
Switching for a moment, I will take some of the remaining time to talk about Transactional Memory Study Group's work and the latest updated timeline for future C++ Standards.
For my group which is Transactional Memory (SG5), SG5 continued its bi-weekly teleconference meeting to last week's C++ Standard Face-2-Face meeting. The members brought forward a proposal for two types of transactions based on V1.1 of the Draft Transactional Memory for C++ that has been worked on for 4 years. This proposal supports 2 types of transactions:
- an isolated transaction that isolates from non-transactional code (as well as other transactions) through some kind of safety annotations
- an ordinary transaction that allows communication with non-transactional code (but is isolated from other transactions)
These two types of transactions, modulo naming, were accepted and their purpose seems clear and reasonable. We further show different techniques for supporting various levels of safety annotation, from fully static compiled time checking to some levels of dynamic checking to ease the burden for programmers.
It is the intention of the group to bring forward a fully worded proposal for Brisol 2013 as a Technical Specification. I have even heard some people suggesting Standardization if the group feels the proposal is simple enough.
Now some of you have wondered if it is too early for TM. Let me say that HW is coming, with Intel's recent Haswell announcement, and IBM's BG/Q, and previously Sun's Rock. SW TM support has been here for quite some time with Intel's STM support of the 1.0 Draft, and most recently GCC C++ 4.7's nearly full support of Draft 1.1.
And if you think it is still too early, let me say that one of Hans discovery was that locks are impractical for generic programming, because ordering of locks is generally not visible until instantiation. With the introduction of locking (and atomics) in C++11, this now becomes a difficult problem to avoid. Transactional memory is one way to solve the problem. It also helps for fine-grained locking on irregular data structures, and read-mostly structures.
There are real problems with any kind of composability with current atomics and locks that can be best resolved with an optimistic speculation technique like TM.
If you think there might not be enough usage experience, We presented in the May MS summit,
data on longer-term study of graduate students on an indexing application. There was an Overall 14% improvement in overall programming effort with transactional memory with good performance.
Finally, if you are still wondering is transactional memory fast enough? There are many different software transactional memory systems with different performance characteristics, so there is probably going to be one that fits your needs. Specifically, a recent U of T Performance study of a multiplayer Quake game with >100k concurrent players where the requirement is atomicity and consistency for all actions. This demonstrated even in pure STM systems, there was a 33% performance improvement for 4-8 threads.
TM is coming in many different forms (HW, SW, hybrid systems, lock elision), and for C++ to remain in a good place with the many other languages that already support TM, this is the right time to be prepared with a sound proposal.
There is almost too much to report from the Standard and any attempt will be incomplete without taking up more time and space then acceptable in a reasonable blog. The Plenary where all the chairs and subgroup chairs reported took five and a half hours, and this is without controversy. I can not imagine what will happen if controversy arose as that would exceed the amount of time we would have.
Suffice to say that there is a lot of new proposals coming in future C++, and I (and many other blog authors) will try to keep you updated and together, I hope you will get something close to the full picture.
For the future, Herb Sutter who is fantastic at leading the group, proposed a time line to look like this, assuming .1 and .2 as the 2 C++ Standard meetings point. It identifies the time for C++14, C++17, as well as the publication of the Filesysystem (SG3) Technical Specification (TS). Other Study Groups are considering publication of Technical Specifications as well. Our group, Transactional Memory (SG5) is preparing for publication as a TS sometimes during 2015 to 2017. Networking (SG4) is interested in publishing a TS every year, initially with URL specification.
2012.2: C++14 New Work Item Proposal; FileSystem (SG3) New Work Item Proposal
2013.1: C++14 Committee Draft; FileSystem(SG3) Preliminary Draft Technical Specification
2013.2: C++14 Draft International Standard; FileSystem(SG3) Draft Technical Specification Ballot
2014.1: C++14 Final Draft International Standard
2014.2: C++17 Committee Draft 1
2015.1: C++17 Committee Draft 1/2
2015.2: C++17 Committee Draft 2
2016.1
2016.2: C++17 Draft International Standard
2017.1: C++17 Final Draft International Standard
Of course this is a tentative timeline and much could still change.
Ok, this was a long post after a long period of inactivity due to my personal responsibility from leading so many different groups. There is actually a lot more news coming then I can write, I will try to give more smaller bites and more frequent news. But we definitely do live in interesting times.