C++ / Uncategorized

C++17 content prediction(pre-Jacksonville and post-Kona report)

Michael WongLeave a comment

C++17 content (a prediction)

C++17 content will likely close in the next 2 meetings. At the upcoming meeting in Jacksonville, it has already asked that any interested party who wants a major feature in C++17 to put in a position paper, or an opposition paper. We call this the land rush into C++17. Please see previous meeting blog from Lenexa for background.

What will happen is that at Jacksonville, this question will focus our work for the week, with the intention of voting out a Committee Draft(CD) at the following meeting in Oulu in June for National Body Comments. The CD stage is where most comments should happen. This is the national bodies’ first chance to inspect and provide feedback on the committee’s work. After the ballot ends, the comments are collected and the committee has to work through them and respond with a Disposition of Comments. This CD will return comment in the Issaquah meeting in Nov. If there are no major surprises, a DIS will be issued out of that meeting. This is unlikely to be that fast. There will likely be nontrivial changes, such that either we will take 2 meetings to address these comments or a 2nd CD will be issued . With 2 meetings to address comments, the DIS will be issued at the latest in the Feb 2017 Kona meeting, which will result in approval vote in the July 2017 Toronto meeting. There is no need for a FDIS if the DIS passes cleanly. And all this has to happen cleanly such that the Standard appears for sale on ISO and National Standard body websites for sale just before the end of 2017.

C++17 already contains a large number of language and library features as a result of integrating changes from Evolution Working Group, and Library Evolution Working Group. Please see below for a current list of the features.

Language:

 

Library:

But few of them are wide-ranging in their effect on covering all of the programming domains of C++. They still add excellent value to a new Standard, but people are beginning to wonder if it will be as large a change as C++11, not to say that is necessarily a good thing to have that many large changes. Without the addition of something like Concepts or other major features that are broadly applicable to many domains, the two questions everyone has is will it contain any truly major features and if so will they be wide-ranging in their effect on the C++ community, i.e. be broadly applicable to all domains, as opposed to a few domains. The outlook, as they say, is stay tuned.

Cppreference gives a great link of all the current projects on hand.

http://en.cppreference.com/w/cpp/experimental

Of these I can form a similar table stating what is their current status just before the Jacksonville meeting, on their likelihood of making into C++17, as we now have much greater clarity and insight.

ISO number Name Status links C++17?
ISO/IEC TR 18015:2006 Technical Report on C++ Performance Published 2006 (ISO store)

Draft: TR18015 (2006-02-15)

 std::hardware No
ISO/IEC TR 19768:2007 Technical Report on C++ Library Extensions Published 2007-11-15 (ISO store)

Draft: n1745 (2005-01-17)
TR 29124 split off, the rest merged into C++11

 N/A (mostly already included into C++11)
ISO/IEC TR 29124:2010 Extensions to the C++ Library to support mathematical special functions Published 2010-09-03 (ISO Store)

Final draft: n3060 (2010-03-06). Under consideration to merge into C++17 by p0226 (2016-02-10)

 special math May be pending special vote and discussion on Monday

 
ISO/IEC TR 24733:2011 Extensions for the programming language C++ to support decimal floating-point arithmetic Published 2011-10-25 (ISO Store)

Draft: n2849 (2009-03-06)
May be superseded by a future Decimal TS or merged into C++ by n3871

 decimal32
decimal64
decimal128		 No
ISO/IEC TS 18822:2015 C++ File System Technical Specification Published 2015-06-18. (ISO store). Final draft: n4100 (2014-07-04) filesystem May be pending special vote and discussion on Monday

 
ISO/IEC TS 19570:2015 C++ Extensions for Parallelism Published 2015-06-24. (ISO Store). Final draft: n4507 (2015-05-05) parallelism May be pending special vote and discussion on Monday

 
ISO/IEC TS 19841:2015 Transactional Memory TS Published 2015-09-16, (ISO Store). Final draft: n4514 (2015-05-08) transactional memory No
ISO/IEC TS 19568:2015 C++ Extensions for Library Fundamentals Published 2015-09-30, (ISO Store). Final draft: n4480 (2015-04-07) library extensions May be pending special vote and discussion on Monday

 
ISO/IEC TS 19217:2015 C++ Extensions for Concepts Published 2015-11-13. (ISO Store). Final draft: n4553 (2015-10-02) constraints and concepts May be pending special vote and discussion on Monday

 
ISO/IEC TS 19571:2016 C++ Extensions for Concurrency Published 2016-01-19. (ISO Store) Final draft: p0159r0 (2015-10-22) concurrency No
ISO/IEC DTS 19568:xxxx C++ Extensions for Library Fundamentals, Version 2 DTS. Draft: n4564 (2015-11-05) library extensions 2 No
ISO/IEC DTS 21425:xxxx Ranges TS In development, Draft n4569 (2016-02-15) No
ISO/IEC DTS 19216:xxxx Networking TS In development, Draft n4575 (2016-02-15) No
Modules In development, Draft p0142r0 (2016-02-15) and p0143r1 (2016-02-15) No
Numerics TS Early development. Draft p0101 (2015-09-27) No
ISO/IEC DTS 19571:xxxx Concurrency TS part 2 Early development No
ISO/IEC DTS 19570:xxxx Parallelism TS part 2 Early development. Draft n4578 (2016-02-22) No
ISO/IEC DTS 19841:xxxx Transactional Memory TS part 2 Early development No
Graphics TS Early development. Draft p0267r0 (2016-02-12) No
ISO/IEC DTS 19569:xxxx Array Extensions TS Under overhaul. Abandoned draft: n3820 (2013-10-10) No

 

At the pre-meeting call which I and other senior leaders of the C++ committee participate, one of the first call was a planned discussion on the first day of plenary at Jacksonville of several major projects with the goal of using what precious time we have to focus on those that have a good chance of making it.

  • FileSystems TS
  • Parallelism TS1
  • Library Fundamental TS1
  • Concepts TS
  • Special Math IS

These are the most likely candidates for C++17 that has been in existence as a TS, may have enough usage experience, and is of definite interest to some group.

Of these FileSystems TS and Parallelism TS will likely have the most amount of support to move forward, mostly intact, but you never know. LF TS1 will likely have some parts of it separated out according to the following table courtesy of Marshal Clow:

Feature Sections Notes Implementations
apply() 3.2.2 gcc
Variable Templates For Type Traits 3.3.1 Already added to C++17
Invocation type traits 3.3.2 None?
optional 5 gcc
any 6 gcc
string_view 7 gcc
shared_ptr with array support 8.2 gcc
polymorphic memory resources (PMRs) 8.4, 2.1, 4.2, 9.2, 9.3 gcc (partial)
search 4.3, 10.2 gcc
shuffle 10.3 gcc

 

For Concepts, the main question is how important will be separate checking and whether there is no way forward for definition checking of templates. Is definition checking a big deal as it was one of the reason the original Concepts C++0x was pulled in the “Frankfurt Accord”? Will it take a long time to be added after current Concepts “Lite” constraint checking is added. I personally do not see definition checking as a big impediment, and if people want definition checking, it will be done. Waiting for it is the essence of Perfect is the enemy of Good, and Good in this case is good enough.

Special Math is interesting as it has been its own IS for sometime, and now is interested in being added to C++17. There is now much more High Performance Computing interest attending C++, so it is no longer a small domain. C++ has a real chance to be enabled for this important domain which covers not just nuclear research or astronomy, but oil and gas, and many consumer domains. It will be good for C++ to have this.

In order to move forward, there will be a three-way vote to decide on each of these questions to judge how many are firmly decided that this should be in, or not in C++17, and how many are still undecided, pending more work. This will lead to some item be dropped from consideration immediately if there is an overwhelming majority against it., to allow time for other more likely candidate to move ahead.

We already had a number of proposals in this and other areas put forward by SG14:

P0249R0 Input Devices For 2D Graphics Brett Searles 2016-02-05 2016-02   SG14
P0267R0 A Proposal to Add 2D Graphics Rendering and Display to C++, Michael McLaughlin 2016-02-12 2016-02 N4073 SG14

 

P0037R1 Fixed point real numbers John McFarlane 2016-02-11 2016-02 P0037R0 Library Evolution, SG14  
P0040R1 Extending memory management tools Brent Friedman 2016-01-10 2016-02 P0040R0 Library Evolution, SG14
P0059R1 Add rings to the Standard Library Guy Davidson, Arthur O’Dwyer 2016-02-09 2016-02 P0059R0 SG14, Library Evolution
P0203R0 Considerations for the design of expressive portable SIMD vectors Mathias Gaunard 2016-01-26 2016-02   SG14
P0230R0 SG14 Games Dev/Low Latency/Financial Meeting Minutes 2015/10/14-2015/02/10 Michael Wong 2016-02-12 2016-02   SG14
P0232R0 A Concurrency ToolKit for Structured Deferral/Optimistic Speculation Paul McKenney, Michael Wong, Maged Michael 2016-02-12 2016-02   Concurrency, SG14, Evolution  
P0233R0 Hazard Pointers: Safe Reclamation for Optimistic Concurrency Maged M. Michael, Michael Wong 2016-02-12 2016-02   Concurrency, SG14, Library Evolution  
P0234R0 Towards Massive Parallelism(aka Heterogeneous Devices/Accelerators/GPGPU) support in C++ Michael Wong, Hartmut Kaiser, Thomas Heller 2016-02-12 2016-02   Concurrency, SG14, Evolution  
P0235R0 A Packaging System for C++ Guy Somberg, Brian Fitzgerald 2016-02-05 2016-02   Evolution, SG14  
P0236R0 Khronos’s OpenCL SYCL to support Heterogeneous Devices for C++ Michael Wong, Andrew Richards, Maria Rovatsou, Ruyman Reyes 2016-02-12 2016-02   Concurrency, SG14  
P0237R0 On the standardization of fundamental bit manipulation
utilities 		 Vincent Reverdy, Robert J. Brunner 2016-02-12 2016-02   Library Evolution, SG14
P0193R0 Where is Vectorization in C++‽ JF Bastien, Hans Boehm 2016-01-21 2016-02   Concurrency

Kona trip report look back

The last time we were in Kailua-Kona for a C++ Standard meeting was just after C++11 was released, and we had successfully justified the requirement for a new Study Group SG5 Transactional Memory. We are now back in Kona again, always a favorite destination and sure to draw many more people to come to the Standard Meeting, and we have just completed publication of SG5’s Transactional Memory Technical Specification, and starting a new Study Group SG14 on Games Dev/Low Latency/Financial.

Kailua-Kona on the Big Island of Hawaii is in some sense trapped in time, as over the last fifteen years I have been coming here, it has barely changed. Most of the same shops are still in the same place. But the rest of the Big Island has changed (with new volcanic eruptions) and C++ is very different from when I first started coming here.

Today, C++ has 14 Study Groups, have over 100 people attending, and is being updated every five years or less. We are closing on the cutoff date for C++17 features which will likely be the next two meetings in 2016. After that, we will likely be drafting the final changes for ratification in time for C++17 publication, which can have a pipeline as long as eight months.

Over the last decade, the Canadian delegation has grown from just me to 10. At this meeting, there were so many Canadians attending that I would need to do a special Canadian count during formal country ISO votes. We had the following Subject Matter Experts from Canada:

  • Michael Wong, ISOCPP.org, OpenMP CEO (HoD)
  • Hubert Tong, IBM
  • Tony Van Eerd, Christie Digital
  • Botond Ballo, Mozilla
  • JF Bastien, Google
  • Patrice Roy, Sherbrooke Universite
  • Eric Fiselier, Bloomberg
  • Michael Park, pending
  • Xing Xue, IBM
  • Chris Cambly, IBM

Whereas before, I was the only trip report and covering multiple rooms, now some of them have written great trip reports and can help me to cover other rooms which are occurring simultaneously.

I mostly hang out in SG1 concurnecy where I co-chair some sessions while sometimes chairing my own SG5 Transactional Memory and SG14 Low Latency. I would attend Evolution, Library Evolution, Core, or Library sessions as needed to advance individual proposals.

For the first time, in French, Patrice Roy, a professor from Sherbrooke Universite has written this report:

http://h-deb.clg.qc.ca/Sujets/Orthogonal/wg21-2015-Kona.html

While Botond Ballo has continued in-depth coverage of the Evolution Committee but also an excellent general overview of the entire proceedings.

https://isocpp.org/blog/2015/11/trip-report-cpp-standards-meeting-in-kona-october-2015-botond-ballo

At this session, I worked to advance a number of proposals for SG14 which means unlike previously where I spent most of my time in SG1 Parallelism/Concurrency, I would move around between all the committees.You can see here for a SG14 paper status report out of Kona.

Description of the major projects

Given the many well done blogs on the content of these meetings, it seems most useful to focus for this blog what major features will get into C++17.

What will Definitely will be in C++17, essentially in nearly complete form

The Filesystems TS is the first major TS accomplished since TS started becoming the way Evolution Groups (Both Language and Library) explore major features without getting bogged down. This features enables a uniform way of accessing filesystems submerging the differences between Unix, and Windows (for example, the back vs forward slash, and awareness of capitalization). It has been a Boost library for quite some time under Beman Dawes and its addition to C++17 is certain. There will likely be a second version of this because as it stands it does not deal with filesystems such as Network filesystems, or that which exists on mainframe systems. These will likely be added in future TSs.

Parallelism TS will contain Parallel (and Parallel and vectorized versions) versions of STL. It has been published with many implementations and there is no reason to think it will have any changes on it for inclusion into C++17 fully as is. It contains the seed that will form the future of massive parallelism as we move forward to support accelerators.

Library Fundamental adds a number of useful functionalities in the form of optional, any, string_view and much more to the Library. It has been published and parts will certain to be in C++17. There will be controversial parts that would be left out.

What may make it into C++17, at least some part of it in some form.

Concepts (lite) TS is a constrained template mechanism that enables the template side to have a prototype mechanism to offer a much more useful template mechanism that finally solve the error novel problem whenever a template client does not match what the template requires. This has been a long standing problem in C++ that would have been solved with the original Concept proposal. But in Frankfurt back in 2007, it was shown that the existing design would mean even simple uses of template would require knowledge of Concepts. That was because it contains extensive template dfeinition checking as well as a Concept Map mechanism for abstraction of archetypes. That original Concepts proposal was removed in a critical vote, which will forever be known as the “Frankfurt Accord”, although few people know about that.

What will Not make it into C+17, but will be on deck for C++20 or C++22.

Concurrency TS contains improvements to futures, latches and barriers, and atomic smart pointers. Although there is implementation experience, it was just approved and is too fresh to be voted to be added to C++17. The futures improvement are language changes but are already in well tested in Microsoft’s Visual C++ and C# compilers. The other two features are library additions. Latches and barriers have been used in Google, and atomic smart pointers are just a syntactic sugar on top of smart pointers such that it has a first class name. In future, it will form the basis of a future marriage with the Parallelism TS to form the basis of the support for SG14’s design for Accelerator support for Massive parallelism. The future mechanism is ideal in conjunction with parallel STL to enable dependency with bulk dispatch.

Library Fundamental TS2 already contains a rich amount of content because the work is still ongoing. It already has source code information and various utilities. As this is being balloted by National Bodies, it will be approved before the deadline for C++17 cutoff in the next two meetings but is too fresh to be considered for C++17.

One of my two groups, the Transactional Memory TS has a well defined specification that has already been approved to publish. It will very soon have implementation in GNU V6 in 1H, 2016. We also have been exploring Wyatt Technology usage in industry and learning from their experience of using TM in their code. We still need more experience from usage of the TS form and GNU will give us that. Without that usage experience, SG5 volunterily does not proposed this to be added to C++17. Most likely, if any part is to be include, then the synchronized form of the construct is the most likely candidate. Unlike the atomic form, It enables a simple replacement for locks, that is composable (whereas locks do not compose) , and usable immediately in that it works with any current code (even transaction unsafe code). Of course, the downside is that it will become irrevocable as soon as a transaction unsafe action is performed, and will commit all of its actions. This makes it possible to be not well-scalable.

Networking TS is based on established practice in Boost’s ASIO library by Christopher Kohloff. It is a socket library and much of it was reviewed last year in a special Library meeting with current wording review in progress. It is a large proposal and as such, despite its well formed historical basis, some details has changed from the original Boost.ASIO. It will not make it into C+17.

Ranges TS has been called STL2, and instead of iterators will use range-based algorithms. It was specially commissioned by ISOCPP.org and designed by Eric Niebler, an expert long-time Boost developer. It is also design review complete with wording review in progress. It is a very large change enhancement and while there is wide interest and support behind it, it is still too fresh to make it into C++17.

Parallelism TS2 is already on the deck with major features such as Task blocks, agents, progress guarantees, and SIMD. In fact, a joint SG14/SG1 call last week just established SIMD in a form that essentially accepts implicit wavefront as the way to move forward, modulo a few semantics corner cases with multiple threads writing to the same SIMD lane, causing either undefined or well defined industry behavior (ordered by whichever writes last). At some point in the future, this TS may also add mapreduce and pipeline capabilities.

Numerics TS (SG6) is still under development with additions for Fixed point arithmetic, DFP, and future support for IEE754 128-bit floating point. It has been meeting on and off as the chair cannot attend every meeting. This likely will have less chance of making it into C++17, although individual proposals such as fixed point still may.

Array extension has had a checkered past and likely similarly checkered future. It is a stack array with size that is not known at compile time. It has been started, then pulled out, then at Kona, direction was given after a special discussion in EWG to that can be used as framework for future proposal. It will not be in C++17

See you after Jacksonville meeting. Thanks.

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s