Originally posted by: Michael_Wong
I apologize as this report is late due to several back to back conferences through September. At this meeting, the most important thing was to address as many of the National Body (NB) Comments from the draft C++14 CD possible. This will enable us to be in good shape for the release of C++14 in 2014. Please look at my blog series to get an idea of the major content. However, this meeting did have some interesting minor changes which modified that content. This is fairly normal to decouple features which is still controversial. The biggest change is the moving of VLA (or what we called Array of Runtime Bound) and dynarray into a library array TS, and the adoption of the single quote as a digit separator for C++14.
First, the number of comments for this draft is considerable less than that for C++11, reflecting the smaller content and higher quality. There were 115 NB comments. There are 85 gathered in:
N3733 ISO/IEC CD 14882, C++ 2014, National Body Comments
which has the official NB responses. Due to a minor misunderstanding at ISO HQ where the Canadian comments were sent to the C committee incorrectly, the Canadian comments were embedded in a separate document
N3771
|
Canadian C++14 Comments
|
Almost all comments were addressed in both documents which is what is important.
Sixty-six of these comments were for core: 36 from N3770 and all 30 from N3771. Core dealt with both sets but referred some of the extension requests and design issues to EWG for initial evaluation. Of the 66 aimed for core, most issues had resolutions in ready state which mean they will be available to be moved in the next C++ Standard meeting in Issaquah in Feb 2014. A few of the remaining ones are still being drafted. Nine were rejected and six are left pending as opened feature requests. Core status on the NB comments are in:
N3770
|
C++ CD Comment Status, Rev. 1
|
There were several additional papers which still needed to be injected into C++14. These were:
N3760
|
[[deprecated]] attribute
|
N3781
|
Single-Quotation-Mark as a Digit Separator
|
N3778
|
C++ Sized Deallocation
|
Some explanation is required. N3760 was an approved feature from EWG to add the [[deprecated]] attribute but it was not reviewed in core. This effectively approves it for C++14.
The next one is the bike shed. I even talked about it in my Going Native C++ talk on C++14: Through the looking glass:
http://channel9.msdn.com/Events/GoingNative/2013/Cpp14-Through-the-Looking-Glass#comments
The original solution of using underscore, but using the double radix (..) for disambiguation for when separator underscore and the leading underscore of the user-defined literal became ambiguous was rejected in the last C++ Standard meeting in Bristol. There were 3 NB comments to find a solution and after some consideration, they went back and approved one Daveed’s proposal (one of my original favorite) of using a single quote as digit separator. A single quote is already used by some countries as a separator, although you are familiar with the use of comma in NA and decimal in Europe. The original concern was that a single quote mean some Language tools would confuse it as opening a quote and start looking for a closing single quote. I always felt this was an overly cautious concern. In this meeting, it was made clear that what we should care about most should be in the order of:
-
C++ Language Users
-
C++ Language Implementors
-
C++ Language Tools
When viewed in this light, it became clear what we should care about first and if such a change is good for the language and is asked for by the users (3 NBs) and easy enough to implement, then we should do it. So this was approved for C++14. So C++14 digit separators will be universal, and does not interfere with user-defined literals. For example, the number twelve can be written 12, 014, or 0XC. The literals 1048576, 1'048'576, 0X100000, 0x10'0000, and 0'004'000'000 all have the same value.
One area where this change can have backwards incompatibility is with C++11 macro invocation. This is because the single quotes delimit a character literal in C++2011, whereas they are digit separators in C++14. This means the following example from the paper is valid in both Standards but produces different results:
#define M(x, ...) __VA_ARGS__
int x[2] = { M(1’2,3’4) };
// C++2011: int x[2] = {};
// C++2014: int x[2] = { 3’4 };
This was approved with a great sigh of relief as many, myself included do not want to spend any more time on this topic. However, enough felt that it was important enough to have a solution, although slightly unsatisfactory as the universal preference is still the single underscore.
The next paper N3778 was also not new, but clarifies N3663 which was approved for C++14 with one important change. Global deallocation function now takes 2nd param to describe size of memory to be deallocated. Static member function already has this. This omission has performance consequences. However, it seems that improvement has been implemented by EDG, and GCC, and in the latter case obtained significant performance improvements. The new information indicates it does not break valid C++11 code. But there is a potential ABI breakage here as the interface now has that additional size parameter. From the paper, it stated that “The primary problem occurs when the system allocation library is new, but an interposed user allocation library is old. In new programs, calls to the unsized version would go to the user library, but calls to the sized version would go to the system library. However, as currently defined, by default the sized version calls the unsized version. Programmers that desire the improved performance must take positive action. The intent is that in some future standard, this default will change. In that case, there would be a mismatch in allocators."
Library Evolution Working Group (LEWG) is a somewhat new group that started in the last few meetings to parallel the Evolution Working Group that reviews and approves features before they go to Core language. Library Evolution will review and approve features before they go to the Library Working Group. LEWG proposed several new TSs for future Standard inclusion. They were the creation of
-
Library Fundamental TS
-
Array Extension TS
-
Parallelism Extension TS
-
Concurrency Extension TS
Library Fundamental TS will start with the N3672 optional feature which was narrowly passed but had a large number of NB comments indicating dissatisfaction with its proposed interface. To answer them, this has now been moved out of C++14 into a TS.
Array Extension TS contains both VLA (or ARB) and dynarray feature which was originally approved for C++14. VLA is fine, but dynarray has an interesting property which allows it to switch from the heap to the stack. This capability was not well understood before and is probably even more problematic to implement properly. This became effectively the new bike shed after digit separator was approved. There is a desire for VLA as a facility to transition existing uses of T[] and ptr+size more safely then what C99 VLA offers. T[] and ptr+size is a major source of bugs in C++. You cannot cast VLA. They decay to a pointer at the drop of a hat and you cannot get begin and end iterator. You can’t use Standard Algorithms on arrays. So it was deemed that VLA alone would do more harm then good. But dynarray provides the migration out of that into a library array facility that does neatly solve all these problems. But we find there were too many remaining question on its implementation. There was also a desire to keep these two facilities together, even though one is better understood then the other. So after a great deal of discussion, it was decided to pull both features from the C++14 draft and provide them both as a Library Array Extension TS. This will provide time for the implementation of dynarray to stabilize.
We had a between Std meeting SG1 concurrency meeting in July hosted by Nvidia where we discussed the idea of hosting several TSs for SG1. Two of these materialized as TSs this week. The Parallel Extension TS contains N3724 which was revised to:
N3554
|
A Parallel Algorithms Library
|
The Concurrency Extension TS contains N3731 and N3721. N3731 was revised to
N3785
|
Executors and schedulers, revision 3
|
and N3721 was revised to:
N3784
|
Improvements to std::future<T> and Related APIs
|
post-meeting. This is the beginning of a whole set of advanced parallelism features which include the following:
Parallelism TS to be started when any of the following three are available:
-
Parallel Algorithms: this initiated it in N3554
-
Data-Based Parallelism. (Vector, SIMD, ...)
-
Task-based parallelism (cilk, OpenMP, fork-join)
In addition, other candidates for the Parallelism TS in future are:
The concurrency TS will also follow the idea of whatever is ready to be publishable first:
-
Future Extensions (then, wait_any, wait_all): This is N3784
-
Executors: This is N3785
-
Resumable Functions, await (with futures)
Additional content could come in the form of:
-
Counters
-
Queues
-
Concurrent Vector
-
Unordered Associative Containers
A further Synchronization TS could appear in future with the following features:
-
Latches and Barriers
-
upgrade_lock
Technically, SG5 Transactional Memory is really also about advanced synchronization, but is too big to fit into the Synchronization TS, and will appear as its own TS.
Library had 42 comments which are also mostly addressed through this meeting with a very few rejected although N3770 still shows them as unresolved, due to the larger workload. Some of the significant ones were GB9 which removes gets from the library. Complex imaginary constants now finally has user-defined literal suffixes. Specifically, there was controversy before on using i_f for imaginary float because there was concern that if as a UDL suffix may be a problem with as “if” is also a C++ keyword. The only caveat is that there must be no space between the “ and if so if must appear as follows
operator “if ( …)
This is now in C++14.
US21 was a comment to deprecated rand and its friends according to N3742. The proposal is to deprecate of std::rand(), std::srand(), RAND_MAX, and random_shuffle(). The rationale for deprecating rand and its friends are that it is perceived as giving inefficient or poor results depending on what implementation you may be using. The rationale for deprecating random_shuffle() is that one overload is specified so as to depend on rand, while the other overload is specified so as to require a hard-to-produce distribution object from the user; such a distribution is already an implicit part of shuffle, which we retain. The advice was to move to C++11 <random>. Deprecated here means we put the world on notice that we might someday remove them from the Std and put into Annex D. Vendors will likely still support it but there is no guarantee. The problem is that this generated a great deal of controversy concerning whether this perceived inefficiency is an implementation detail which resulted in insufficient consensus for deprecating rand. There might be more consensus to deprecate random_shuffle.
For the remaining TSs, the Networking TS has its first document:
N3783
|
Network Byte Order Conversion
|
The Filesystem TS has already delivered a document and it will be moving to a PDTS.
N3803
|
Programming Languages -- C++ Standard Library -- File System Technical Specification
|
For all the TSs, there was a discussion on what is the appropriate namespace for a TS. For TR1 we had an additional namespace called TR1, but that is sometimes not uniformly implemented by all compilers, with some putting it in the Standard namespace and others following the TR1 prescription. The idea of an experimental namespace tag for TS means that there is no uncertainty that this is an experimental interface. So what is emerging is the following:
std::experimental:: ...
Expect that now for TSs, as TSs are not normative. Many of these TSs are still meant to be shipped near the C++14 timeframe.
These plenary sessions are getting longer and longer because there are thirteen subgroups reporting that I will group those into a separate blog. Yes, you heard it, thirteen subgroups.