C++ 14 is here, and its proceeding to publication this year. On Aug 18, C++ 14 was formally ratified.
We had one C++ Standard meeting since my last blog post for Issaquah Standard meeting, and that was in Rapperswil, Switzerland in June 16-21. We were there several years ago, and it is always nice to be in among the pristine lakes of the Switzerland Alps.
Jens Weller, who runs Meeting C++ has described a few of my recent talks on C++14 at C++Now (as well as previously at ADC++ 2014) as well as ongoing video interviews on my various thoughts on OpenMP and TM in his post on Thoughts on C++14
“But I already have written about C++14 and Michael Wong gave an excellent talk about C++14 features at C++Now this year. I've also recorded an interview on C++14, the C++ Standard and other things with him. “
As I am writing this (which is much delayed due to workload and preparation for airplane time again as I begin my fall business trip after 2 months home working on a special project), I am back in Issaquah to attend CPPCon giving 2 talks, 3 panels, and several interviews.
http://cppcon2014.sched.org
One talk will be on Accelerator/GPU programming using OpenMP and our progress of bringing OpenMP to Clang. The second one will be on Transactional Memory in C++.
I am serving on 3 panels
- Authors panel (I guess someone heard of the C++11 book I wrote in Chinese last year, although I have been simply too busy to blog about it)
- Grill the C++ Standard Committee Panel
- C++ Concurrency future panel
But before then, I attended a C++ Standard Parallelism Summit at Microsoft (thanks to MS for hosting, who always consistently do so much for C++, such as hosting, and initiating ISOCPP.org, and Going Native Conferences which morphed partially into CPPCon, much of that thanks to Herb Sutter, specifically) to look at the latest changes to the Executor API and asynchronous operations, execution agents, a language form of co-routines/resumable functions and for me, a possible fix to the atomics consume operations, and possibly an ability to support atomic operation for non-atomics. I will update on what we heard in the next blog post. But I love the new Coroutine design by Gor.
In the Rapperswil Standard meeting, we were not allowed to update the Working Draft of C++14 because it is being balloted as a DIS. For now, this remains on track for C++14 ratification in 2014.
However, there is plenty of work as five Study Groups (SG) were aiming to move from New Proposal (NP) to the next step of achieving Preliminary Draft Technical Specification (PDTS), though not all succeeded as you will see by the end of this blog. You can see this in an image of the status taken before the June meeting and after the June meeting to see the differences.
Library Fundamental and Parallelism TS remains on track for a PDTS after the June meeting. My Transactional Memory SG has elected to aim for PDTS in the next meeting, so this meeting was busy with processing all the wording changes we plan to inject into a TM Working Draft. Concepts also plans to delay PDTS to the next meeting after substantial wording processing in this meeting. Both TS will be holding in-between meeting telecon calls to process more wording changes. Array TS, originally aiming for a PDTS at the June meeting was removed but could come back. Continue reading in this blog.
FileSystem continues to aim for the final stage, a Draft Technical Specification, (DTS) and should succeed as it is currently in ballot.
Core had no ballots because C++ 14 DIS was under ballot. They were still busy as they were reviewing wordings for prospective TSs which could become features of C++17, reviewing wordings on proposals from Evolution, and processing issues.
Concept Lite review was the first item and it was done very thoroughly. Fundamental design is sound, but there were a number of details that need update. These update would require another meeting so it was not ready for a vote to move forward to a PDTS at this meeting. There would be an attempt to review this in-between meeting with the aim of putting out a PDTS in the next meeting. Aug 4 was a telecon and Sept 15 will be another telecom.
Core also reviewed SG5’s Transactional Memory in a second core review (the first one was already held in-between meeting) and asked for a specific change. While SG5 has talked about the need to offer more flexibility to users with a safe-by-default design (which requires the generation of both transaction-safe and transaction-unsafe version of functions so that at link time one version can be thrown away, when the linker can see both versions and knows which version is really needed) and up till now no one has seriously objected, one objection was posed in this review and this one was a serious objection on this design from one of the reviewer. The argument essentially balances between what is convenient for the users but adds code-bloat in terms of dual generation of functions, and what is more straightforward, albeit less convenient to users but require static compile-time generation of errors when transaction-unsafe operations are used.
Fortunately, what Core asked for was a design that was already discussed extensively by SG5 in a previous design, and is what is implemented today in GCC 4.7. It was a simple matter to get approval from the SG and then Evolution, and this return to an old design was approved.
So in essence, what this means is that explicit annotation (of transaction-safe or transaction-unsafe) is required for extern entities that are non-template inline functions or an inline function if declared without a body if it’s used before definition (likewise for templates).
Even though we are still in the process of releasing C++14, there are now features in the pipeline for C++17, and almost all the following discussion, including all the TS are candidates for C++17. The new language features are:
There seems to be always more work for core to review and now there is plan to have one telecom per month. SG5 TM will have its telecon call in September to bring the revised wording based on the above change for a third review. Concept-lite will also have a Core wording telecon call in late September.
Library is responsible for reviewing wording changes to the Library chapters and the key item they had to complete was the processing of fixes to comments generated from the FileSystem TS. This wording review was completed with only a few minor issues and SG3 Filesystem was approved to move to a DTS, the final stage of National Body voting. This will likely mean FileSystem TS will appear in early 2014, and some part of it will be in C++17.
Library evolution handles designs for library and does a preliminary review of wording before it is handed to Library.
Evolution (EWG) now moves in to full C++17 mode and starts to look at a large number of new proposals. One interesting outcome is the likely possibility of forming an embedded system study group. The following proposals got encouragement for further work (some has no numbers as they were processed by EWG in real time:
I really like Herb's paper on portable C++ ABI , even though some of the other Open Source community were lukewarm to it. Herb outlined problems of C++ Std Library ABI breakage that makes it difficult to ship updates/fixes/performance improvements to the C++ Library and this problem is common at IBM and Microsoft. He proposes 2 phases where there is a standard name for the one-less then current version of the C++ Standard Library. I intend to work with him on this.
The following proposals were passed with some modification:
- N4051 typename/class, Richard Smith's paper.
- N3981 Trigraphs, (removing trigraphs): SF 9, WF 6, N 6, WA 3, SA 2.
- Concepts resolutions as requested by Core
- N4029 Let return Be Direct and explicit (only when braces are used): SF: 3 F: 8 N: 3 A: 0 SA: 4
- N4026 Nested namespace definition, (JUST the basic syntactic sugar, no attributes, no aliases, no inline): SF: 11 F: 5 N: 3 A: 0 SA: 0
- SG10 clarification on has_cpp_attribute (function style): SF 7, WF 9, N 4, WA 0, SA 0.
I will have a lot more to say about N3981 Trigraph removal at the end of this blog as I argued strenuously against it and I was one of the Strongly Against Vote.
And here are the ones that did not pass and their votes, but some of them may come back with modification:
Bjarne pleaded at the end to have proposals that make simple things simple and that proposals be designed to serve the C++ community at large rather than us experts. He gave the example of one interesting and appealing proposal (N3950 Defaulted Comparison Operators), to give the usual comparison operators by default (using the C++11 default feature) to eliminate the tedium and potential errors in hand-written comparison operators. This seems simple, comprehensible, reasonable, has been widely desired for decades and where any solution would do some good. If you want something unusual, then you would not use the defaults.
During the presentation, this generated into at least eight votes on separate sub-parts of the proposal where there was interest in many variations including symmetric operations, default as globals, negated operators, and mutable members. This conversation continues on the reflector after the meeting. Bjarne will likely present this as a canonical example in his keynote at CPPCON.
You will notice that the Array TS has now disappeared from ISOCPP.org status. The Array TS is in some trouble as discussion and concerns about its implementability continues. While some element of the Array TS that were added in the last meeting, such as array view is heading to a Library Fundamental 2 TS to disentangle it from the Array TS, the ARB and dynarray part remain in limbo and some have asked whether it should be canceled. We are not at that stage yet as the project editor (which is Lawrence Crawl) was not at the meeting and have proposals in the pipeline. The future of the TS will be discussed in the next meeting.
SG1 did a large amount of work on the Parallelism TS which contains the proposal for parallel library algorithms and parallel exeuction policy of seq, vec, and par. It was reviewed in LEWG and LWG. The vec policy has been changed more correctly to parvec, because it is really both vectorization and parallelization. The vector execution policy was improved by N4070 Improving the specification of the vector execution policy in Parallelism TS to contain description of vectorization-safe functions. They also approved N4063 On Parallel Invocations of Functions in Parallelism TS which specify that sort may make parallel invocations to swap, but only if the arguments for concurrent calls don’t overlap. A companion proposal for Task regions (N3991 Task Region R2) was approved but did not make it for inclusion due to workload in LEWG/LWG and will likely be added in future Parallelism TS. This paper proposes the difference between terminally strict fork join (openMP-style) vs totally strict fork join and adapts the latter for the task region proposal for SG1 Parallelism TS. This does not prohibit future inclusion of strict fork join parallelism.
SG1 also reviewed papers on SIMD polymorphism, and lightweight execution agents with the guidance to move forward for Parallelism TS. Parallelism TS N4104 looks like its in good shape and remains on schedule to issue a PDTS for the November meeting, and a DTS afterwards. Its brother, the Concurrency TS was not so lucky as you will see next.
The Concurrency TS N3970 had major surgery in that executors were removed, because there were some ongoing controversy over its design (mostly using virtual dispatch instead of templates, adaption for Concepts). However, new additions were approved such as the anticipated timed shared mutex (N3995 A proposal to add shared_mutex (untimed)) and ostream buffers (N4069). Minor edits were called for in N3998 Latches and barriers but was essentially approved.
The Coroutines proposal was discussed but SG1 asked for unification with Fibers and resumable functions as well as a comparison for stateless and stateful design. This would mean bringing in Language support, as opposed to pure Library support. I support this move as I feel it would allow better inlining and optimization when coroutines has some element of it in the language as opposed to just a pure library.
There follows a clarification for WG14 on the initialization of atomics, is_lock_free() and alignment in SG1.
The remaining continuing items for discussions are synchronized wrapper, and atomic operations on non-atomic data.
We had a major presentation by Gaby on N4047 Modules proposal in SG2 general session and there is significant intersection with Daveed and Doug’s original proposal that needs to be discussed.
SG7 (reflection) looked at N3972 Source-Code Information Capture, N4027 Type Member Property Queries and N3984 Adding attribute reflection to C++ all seems to need champions to move forward.
SG13 was Graphics but is now called Input/Output had a paper N4073 A Proposal to Add 2D Graphics Rendering and Display to C++ that is moving forward in LEWG.
Library Fundamanetal TS is moving forward for a PDTS vote, but a few more things were added to the TS:
N4075 Centralized Defensive Programming support for narrow contracts for a future C++ LF TS was rejected. There many objection in full plenary to this style of programming, despite it having been accepted in LEWG and LWG. The concern was that this is a library solution to a common language wide problem, and even though it may be a good solution, there need to be wider participation in its discussion from the Language group as well. There is plan to continue this discussion.
With the approval of Library Fundamental Ts, there needs to be a new vehicle for experimental Library features and this will be in Library Fundamental 2 Ts. It is also filling with candidates. This also has a good chance of appearing in C++17.
In this meeting, Steve Clamage from Oracle, the INCITS WG21 chair announced he is retiring after the next meeting after serving many years with distinction. He is replaced by Clark Nelson of Intel, the vice-chair. The vice-chair job will be filled by John Spicer from EDG.
The way a TS is moved forward will soon change to have ballot periods similar to that of a Standard (IS). After 2014, TS’s that start PDTS will be allowed to jump to a DIS as long as there is no dissension in the PDTS vote. This is similar to how an IS can advance from a DIS directly to an FDIS.
For this meeting, I worked on the TM proposals rewrite
But I also collaborated with my colleague Hubert Tong ANL's Hal Finkel and members from Clang, Intel and EDG on the new design for a restrict-like semantics for aliasing proposal which I presented in the Chicago meeting, and was overwhelmingly approved to move forward with full design. This was done in:
N3988 Towards restrict-like aliasing semantics for C++
Now for a word about trigraph removal which I strenuously opposed. I almost won as the vote still had 5 opposed with 2 strongly opposed. My main argument is that we had looked at deprecation in the C++11 time using up 2 committees time over 3 meetings of about 20 people each instance , and we decided to pull back from it. So why are we bringing it back again, as we are usually not in the habit of rehashing decisions. Here is the quote from the March 2010 meeting:
"The CWG decided not to deprecate trigraphs, acknowledging that there are communities in which they are viewed as necessary. Instead, it was decided to address what was considered to be the most pressing issue regarding trigraphs, that is, recognizing trigraph sequences inside raw string literals.
The main objection is once again that trigraphs get surprisingly replaced in quoted strings. May be the new movement is that at every new C++ release, we will revisit unpopular decisions."
Consider that this has been reviewed by 2 committees, over several meetings, by many experts. Has any new information been added since the last attempt? IMHO, No
C++11 Raw string is now a viable work-around in quoted strings but I acknowledge that it is unsatisfactory because you have to know you have trigraph replaceable combinations in your string a priori to be able to be not surprised by it. Most modern users object to a portability arrangement that seems to only service a small group.
My many technical arguments against removal or deprecation of trigraph are outlined in a 2010 paper:
N2910 Comment on Proposed Trigraph Deprecation
However, the modern world is largely ASCII and I must accept that EBCDIC and its needs seems to be isolating down to just IBM. This makes this move even more dangerous IMHO because it sets into precedence a move towards the populist vote, rather then what the Standard is all about: portability for all. We must represent and speak even for the silent minority.
There are many applications that remain in EBCDIC (bank check clearing is one important example) and they will never change to ASCII because they have been debugged over 20-30 years of maintenance and they cannot risk rewrite to ASCII due to new bugs that may be exposed.
But I must also acknowledge at what point is that small minority needs to continue to be represented, and this is what the Standard Committee vote is telling me. I differ from the committee in that we need to continue to represent that important constituent even against the face of popular sentiment, and that I still don't think it is that small.
The new proposal is actually quite tolerant and specifically removes trigraph from the Standard mode, but still allows (and advises support in its non-normative encouragement) for support of trigraphs as still a conforming implementation. Most ASCII compilers have already removed trigraph from its default extension. GCC for instance requires you to ask for trigraphs in its default extended mode. In fact, all compilers will retain it as an extension so that portability is maintained. IBM will retain it as a default in its extension.
The Standard removal of trigraphs does not harm IBM, but I and IBM still maintain that it is bad for the C++ language, as it reduces portability and after all, what is a Standard if not because of portability?
For the next few months, it is airplane time again. I rarely show up at conferences much other then for my speaking slot due to my workload but this CPPCon has many interesting talks for which it is worth it to attend. As I said, I am back in Issaquah (was here in Feb for the C++14 Std meeting, and last year at this time for Going Native 2013 talk) for the MS-hosted C++ Parallelism summit last Thursday and Friday and now getting ready for CPPCon. I am skipping the Reception tonight to stay in to work. Immediately after this conference, I have to go to IWMP in Brazil to present 2 research papers on Transactional Memory accepted for publication. After this, I am being reposted overseas for one month as a visiting scientist with many, many talks across Asia and a book tour based on the C++11 book I and others wrote last year, and then I will have to attend the C++ Standard meeting in Urbana, where I plan to present the Official Working Draft for Transactional Memory, explain my trigraph position, and updates on restrict-aliasing semantics. After that, I will need to go to SuperComputing 14 where I am giving several keynotes and public interviews as well as hosting the BoF on OpenMP, and LLVM in HPC. If you are in those areas, I love to talk to you. Thanks.