C/C++ and Fortran

 View Only

C++14: The New Standard, Through the Looking Glass: The View from the Feb 2014 C++ Standard meeting

By Archive User posted Fri May 02, 2014 09:21 PM

  

Originally posted by: Michael_Wong


“This is it”, whispered all the online blogs, the upcoming talks, and the updated versions of C++11 books. C++14 has arrived!

This meeting is historic not just because we completed the practical work on C++14 but because C++ Standard is now consistently shipping a product almost at every meeting. This is the result of the bus-train model where various groups and subgroups always have either a Technical Specification or a Standard to deliver. Expect this from now on from the C++ Standard Committee. The benefit is that a predictable schedule may ease resource allocations for implementers.

The major deliverable is the C++ Standard and what started off just before the Bristol meeting as an idea and continued last year in Chicago is now willed into reality as we completely close on the work of delivering a Draft International Standard (DIS) for C++14 covering any changes from this meeting. Many of the features were discussed in the last blog post, but this meeting does add a few minor changes and update on the progress of various Technical Specifications (TSs). There was nothing as dramatic as the chest-pounding, indignant removal of Concepts from C++0x. Sorry to disappoint you pundits. It does reflect the orderly participation and consensus building process that is evident now.

Indeed, C++14 has none of the dramatic and fanfare that accompanied previous Standard releases. In the Chicago meeting, there was the async concern which became a kind of new bike shed, to differentiate with the digit-separator old bike shed. But really, nothing like the removal of some feature or we are broken, and the world will lament the burden of our mistakes imparted on countless generation of programmers.

C++14 was passed with all unanimous consent on all motions. That’s right, unanimous. That in itself is already historic. This was an achievement no matter on what scale you look at it, because it now involves over a hundred people, many National Bodies, and a concurrent meeting process that at first would confuse any weak memory model theorist on first sight, but is actually simple once you see it in action.

Even though C++14 adds about 20 pages to C++11, from 1353 to 1373. I will outline in this blog what has been changed  in those pages, in addition to that I described in the previous blog post from the Chicago and Bristol Std meeting.

C++14 also lays the groundwork for a continuing pipeline of features to come for C++17, and C++22 in the form of Technical Specifications that will in-time become normative in some form.

Priority for this week for Core was to fix all issues relating to National Body (NB) comments, most were already in ready state after Chicago. Although Core addressed 68 issues, they chose not to immediately move these into C++14 so as not to destabilize the draft.

There were a few minor changes that came out of SG1 concurrency. We tackled the issue of the definition of lock free in C++ in

N3927, “Definition of lock-free” 

And came up with a definition which can work in the presence of fair scheduling, especially noticeable in PPC weak memory models. It essentially involves some thread making progress. The problem was that currently, the Standard statement about lock-free really should be obstruction-free in some cases involving PowerPC, but may be viewed as truly lock-free in other non-PPC architectures. 

We also proposed to rename shared_mutex to shared_timed_mutex in

N3891, “A proposal to rename shared_mutex to shared_timed_mutex”

oo make the naming more uniform, with the intention of filling in the gap later.

We also clarified what a signal handler can do  because in C++11, we made unspecified the interaction of signal handlers in the presence of atomics far too broad and we needed to narrow the definition.

N3910, “What can signal handlers do?”

The others non-trivial changes were

N3887, “Consistent Metafunction Aliases” 

and the following was revised after the concerns on rand deprecation was brought up in the last meeting

N3924, “Discouraging rand() in C++14”

In effect, this completes the changes for C++14. At a broad stroke, C++14 made the following fixes:

Relaxed Constexpr

Typed Tuples

Added missing cbegin/cend

Enabling a group of make_xxx to replace raw new and delete

make_shared(C++11)

make_move_iterator(C++11)

make_unique

make_reversed_iterator

It also had the following fairly major features (IMO) added:

Generic lambdas

Move-capture lambdas

Lamda and normal deductions

Digit separators

Binary literals

Variable templates

Heterogeneous lookup

Quoted I/O strings

UDL suffix for time and complex

As a quick review, here are all the features of C++14:

Language

  • N3472: Binary literals: 0b10001111
  • N3638/N3582: Normal functions can have their returns deduced
  • N3648/N3610: move capture in lambdas
  • N3653/N3605: relax rules to allow member init in aggregate classes
  • N3652/N3597:relax const expr functions
  • N3781: digit separator
  • N3664/N3537: batch new/delete
  • N3651/N3615:constexpr template
  • N3649/N3559: polymorphic lambdas
  • N3323: tweak conextual conv

Library:

  • N3545: adds constexpr operator() to integral_constant
  • N3644: null forward iterator can be compared and value init
  • N3668/N3511/N3608: allow exchange on non-atomics
  • N3658/N3493: template<int...> struct index_sequence { };
  • N3670/N3584: can address tuples by types
  • N3671/N3601: Making non-modifying sequence operations more robust
  • N3656/N3588: adds make_unique
  • N3642/N3531: adds UDL suffixes for time (h,min,s,ms,us,ns) and string(s)
  • N3779: User-defined Literals for std::complex
  • N3733: removed gets was GB9 (notable because it is a removal)
  • N3654/N3570: Quoted Strings Library Proposal
  • N3789: Constexpr Library Additions: functional.
  • N3924: Discouraging rand() in C++14
  • N3887: Consistent Metafunction Aliases
  • N3657/N3456: adds heterogeneous comparison lookups
  • N3669: adds const back to constexpr for library functions
  • N3655/N3546: adds template aliases to Transformation traits
  • N3421: improves <functional>
  • N3462: improves result_of in SFINAE
  • N3302: constexpr complex lib
  • N3470: constexpr container lib
  • N3469: constexpr chrono lib
  • N3471: constexpr util lib

Concurrency (mostly added as Library motions):

  • N3891, A proposal to rename shared_mutex to shared_timed_mutex
  • N3910, What can signal handlers do?
  • N3927 Definition of lock-free
  • N3786: Prohibiting "out of thin air“
  • N3776, Wording for ~future
  • N3659, Shared Locking in C++
  • N3637, async and ~future
  • N3636, ~thread Should Join

Of these the following were moved to TSs:

N3639/N3497: VLA: 1D, no sizeof -> moved to Array TS

N3662/N3532: dynarray <T> supports zero-sized arrays and can be looked at with decltype->moved to Array TS

N3672/N3527: adds class template optional<T>->moved to Library Fundamental TS

I just gave a talk at ADC++2014 on C++14 features. Herb Sutter helped me build up a poem and a play on the theme of Through the Looking Glass (assuming we went down the rabbit hole in C++11 as Alice's Adventures in Wonderland) with apology to Lewis Caroll, which I delivered at last year's GoingNative C++ conference and I will update this talk to the latest status for C++14 at several future talks such as C++Now 2014 and CppCON2014.

“The time has come,” the ISO said, “To talk of many things: 

Of move-capture—

and literals—

Of making lambdas sing—

And why deduction is so hot—

And if digits should grow wings?”

 

We should be seeing C++ programming style and paradigms emerge shortly. Many such as the following are becomin evident

Don't use Raw Loops. Prefer Library functions with Ranged-based for and lambdas

Don't use NULL. Prefer nullptr_t

Don't use raw new/delete. Prefer make_shared and make_unique

Don't use type declarations. Liberally use auto instead.

Others are still being debated such as what is the guideline with the use Special Member functions such as Default Constructor, Copy Constructor and Copy-assignment constructor and whether the addition of Move Constructor and Move-assignment constructor should change it.

Replace Rule of Three. Prefer Rule of Five or Rule of Zero.

So where are the compilers on their implementation status of C++14? This information is courtesy of Marshall Clow who is now the new lead maintainer for clang's libc++.a library.

Clang 3.3 claimed in June 2013 to be Language and Library complete for C++11. GNU 4.8.1 became C++11 Language complete and claims the Library complete in 4.9.

The next release of current clang trunk to be named 3.5 will have a complete C++14 library and language implementation. As clang usually release compiler twice a year, this means a release in June-Sept for 3.5.

What is coming in future for C++17, 22 and beyond. all you have to do is look at the various subgroups of which there are 13.

Library as usual had a large number of motions. But Library also tendered a large number of TSs.

They had augmented the original Library Fundamental TS with many more features beyond the original Optional<T> proposal and added Networking TS proposals to form a new Library Fundamental TS that is aiming for a PDTS ballot after this meeting.

Herb Sutter already named the additions in his excellent post-meeting blog, but I will repeat it here:

The following will be added to Library Fundamental TS N3848:

This meeting was also where FileSystem TS N3940 answered most of its PDTS comments. It will likely complete its ballot resolution in the next meeting where it would be sent out for its final DTS ballot. This would be one of the first TS to reach that status.

Array TS also has a working paper N3820 and was approved and seem to be in good enough shape to advance into an Array TS in Rapperswil with the addition of multidimensional array_view and indexes. It already contains N3639 Runtime-sized arrays with automatic storage duration (revision 5) and N3662 C++ Dynamic Arrays.

Concepts TS had content approved by CWG to be added into initial working paper

N3929, “Technical Specification: Concepts” 

Likewise, SG1 worked hard to add Parallelism TS and Concurrency TS content. The Parallelism TS we  approved before this meeting:

N3850, “Working Draft, Technical Specification for C++ Extensions for Parallelism” 

It contains library to support parallel algorithms for STL that can be made to be run in sequential mode, parallel mode, vectorized mode, or even some vendor mode.

For the Concurrency TS approved, there were 2 features:

N3785 “Executors and schedulers, revision 3” and N3857, “Improvements to std::future<T> and Related APIs” 

These contain a revised proposal based on Google ecxecutors and MS’s extension on futures.

All these have already been TS’s before substantial content was injected. These motions inject meaningful content and mean they may even become PDTSs in the Rapperswil meeting.

My group SG5 TM pushed the envelope of in-flight TSs by adding another by asking and obtaining approval for a New Work item for Transactional Memory based on N3919, “Transactional Memory Support for C++.”

Our group meets twice a week and currently have been putting finishing touches on Standard wording that can be used to turn into an initial working paper in the next 2 meetings between Rapperswil and Champaign. We had presentation in Evolution which provided guidance to the specific syntax chosen for the language. We also had a further presentation to Library Evolution showing our work of beginning the transactionalizing the C++ Standard Library. We started with std::list and found it to be fast and easily made transaction-safe. Transaction-safety is a concept required for libraries to be inlined inside of an atomic block. It requires that the library does not break atomicity.  But we also found some issues which needed review and approval by LEWG.

We are currently dealing with 2 issues left over from our review in Issaquah, where there was a question from Google asking whether a weaker memory model would help deal with the issue of empty transactions or transactions that have local order (which can be the result of compiler optimization that removes the body of the transaction). We also had a question about the interaction between extern template and TM that came out of the Library Evolution review.

If all goes well, we plan to have Standard wording reviewed in between meetings and approval in Rapperswil, and then subsequently Library wording for review and approval in Champaigne, potentially leading to a PDTS in November.

With the practical completion of C++14, there were significant shifts in people. Stephanus du Toit, a long time Canadian SME has been the project editor (he updates the C++ Std Working Draft based on the changes that are approved from each meeting) made the move of putting the C++ Standard into Github and Latex, so that it can have version control and branches. But he will be resigning from active C++ participation. Thank you to Stefanus and to Pete Becker who was the Project Editor who guided us through C++11.  The new editors is a team lead by Richard Smith, with the help of Walter Brown, Dawn Perchik, and Jonathan Wakely.

Kyle Kloepper has been the WG21 and PL22.16 Secretary (meaning he is the official recorder of the discussion during plenary) will be handing his role to Ville Voutilanen, the Finnish HoD. Kyle will take over as Project Editor for the Networking TS. 

Thank you to Kyle, Ville, Richard, Walter, Dawn, and Jonathan for volunteering for these important official positions.

It looks like I will become the Project Editor for the Transactional Memory TS.

In http://isocpp.org/std/status, Herb Sutter has added a project timeline for all these TSs and Stds in flight which significantly clarify where they are going. Thank you Herb, who in addition to being the WG21 Convener, has so capably lead and developed ISOCPP.org into the defacto website for dissemination of the latest C++  knowledge.

Finally, the current five-month DIS ballot for C++14 is technically not the final stage. But if there are no last minute surprises, such as some National Body(NB) voting no, then it is allowed to roll it into the FDIS ballot which is the true final ISO stage. If all NBs approve the DIS, then it is possible for C++14 to truly publish in 2014.  If there are DIS issues, then we will do DIS ballot resolution in the November Champaigne meeting, and we will have a further separate FDIS ballot after November, resulting in final approval of C++14 in Jan 2015. Given the unprecedented unanimous consent of all resolutions from this meeting, this seems unlikely and it looks like we will have a true C++14 in 2014.

The actual C++14 Standard is right now locked:

N3936 Working Draft, Standard for Programming Language C++

N3937 Programming Languages — C++

The last free version which is from the post-Chicago draft (before the changes from this meeting which is minor) can be obtained here:

N3797 Working Draft, Standard for Programming Language C++

As I write this, we are now only 2 months from the next C++ Standard meeting in Rapperswil, Switzerland. I apologize for the delay as I have been delivering talks at several conferences including an Exascale Computing talk at Louisiana State University's Mardi Gras Conference, a  TM and C++14 atomics memory model talk at Euro-TM 2014, an OpenMP 4.0 talk at ACCU2014, hosting the Spring 2014 OpenMP Language Conference at Cambridge University, and more recently talks on TM, OpenMP and C++14 at ADC++14.

0 comments
0 views

Permalink