C++17 and its Technical Specifications

published at 03.03.2016 12:23 by Jens Weller
Save to Instapaper Pocket

Part 2 of my series about the current proposals for C++17. This part is covering the Technical Specifications (TS), which are currently released. Some of them will make it into C++17. Those not making it into C++17, should be available in the namespace std::experimental, if they are not a language feature.

But first, there is a lot of interesting proposals, which are not in a TS yet. Reflection, Modules or constexpr_if are good examples for this. Though, just because it wasn't mentioned in this or the previous post, does not mean anything. I plan a 3rd post, where I will focus on these highlights, which are likely to become a focus of C++ standardization after C++17. My listing of the C++ proposals by subgroup can give you a first overview.

The order of the TS is the order of my listing after subgroups, the Ranges TS and Networking TS happens to be the first two...

Range TS [working draft]

There is some phantastic work from Eric Niebler on ranges in C++, this is the first draft of an TS to add ranges to the standard. (AFAIK) One first change has made it into C++17: the range based for loop supports now different types for begin and end.

This paper assumes that the contents of the std::experimental::ranges::v1 namespace will become a new constrained version of the C++ Standard Library that will be delivered alongside the existing unconstrained version. The versioning mechanism to make this possible is yet to be determined.

Eric Nieblers Range Library is already available and usable today, from C++11 onward. This TS reflects the necessary steps to make Ranges be part of the C++ Standard. A first overview on the range proposals and library should give you Eric Nieblers Keynote from CppCon 2015 "Ranges for the Standard Library".

v1 is a versioning namespace inside of the ranges namespace, this is a common practice in implementing libraries, and was part of Eric Nieblers guidelines for writing C++11 libraries in his Meeting C++ 2013 Keynote.

Networking TS [working draft]

This is an early working draft, its next phase should be to become more mature and after some iterations will become a part of the C++ Standard. As a TS should have the time to gather experience in usage and feedback from the standard library implementers.

On the first view, one expects that this is (boost::)asio, which indeed is the basis of this spec. But this TS has also more details on the asynchronous APIs powering the network code. The TS defines its own executors and other machinery needed to run timers, sockets and events. The networking TS defines the following APIs/header:

• convience header <experimental/net> (aka everything in the TS)
• forward declarations <experimental/netfwd>
• asynchronous model <experimental/executor>
• basic i/o service <experimental/io_context>
• Buffers/Buffer oriented streams <experimental/buffer>
• Sockets, socket iostreams, socket algorithms <experimental/socket>
• Internet protocol <experimental/internet>

The executor header makes this proposal either depend on the parallelism/concurrency TS adding executors (executors do not exist yet in the Standard) or bring its own executors. The Networking TS defines what the needed, generic executor interface is for implementing its asynchronous model. This will likely be synced with the parallelism group, so in future versions I expect to see an exchange of knowledge between the experience of asio and the design of the Standard C++ Executors in a future Parallelism TS.

The internet header brings IP support, but not HTTP.

Parallelism TS [final draft]

The TS is from 2015, a current paper proposing for C++17 is The Parallelism TS Should be Standardized, which also gives a good overview on the current situation. This paper lists 6 implementation of the TS, so that there is enough experience in use and implementation to go forward and include this TS into C++17. The TS it self is rather short, it handles parallel algorithms and execution policies, plus the corresponding exceptions. A parallel sort could look like this:

sort(par,vec.begin(),vec.end())

Where par is the policy, which is proposed as

• par - parallel execution
• seq - seq execution (this could be a fallback, but also is handy if you want to utilize the current thread)
• par_vec - use possibly vectorization and parallelism

With this TS, most of <algorithm> is available in a parallel version.

Concurrency TS [final draft]

This proposal wants to add better future support to C++. It includes the following additions:

• future & shared_future
• promise & packaged_task
• when_all & when_any
• latches & barriers
• atomic smart pointers

This makes std::future a lot better, through adding .then, and making when_all and when_any available.

Transactional Memory TS [final draft]

This will not be added into C++17, but likely to become available through extensions in compilers soon. This would then be a language feature, adding synchronized or atomic blocks to the language:

int f()

{

  static int i = 0;

  synchronized {

    printf("before %d\n", i);

    ++i;

    printf("after %d\n", i);

    return i;

  }

}

Atomic blocks would be available as atomic_noexcept, atomic_cancel and atomic_commit. The TS also plans to add attributes such as [[optimize_for_synchronized]]. You can declare your functions void f() transaction_safe or transaction_safe_dynamic and there are a lot more details, when you want to have transactional memory in the C++ language. The TS deals with all known issues, but the subgroup for transactional memory thinks its to early to add it to the C++ Standard, hence this will be part of C++2x one day.

Filesystem TS [final draft]

The final draft is from 2015, and I already handled a current proposal about adding this into C+17 in the first part of the series. This will be in C++17, and builds upon boost::filesystem. Your compiler might already have its version available under std::experimental::filesystem (include <experimental/filesystem>.

Library Fundamentals TS [final draft]

There is a second version of this TS proposing even more additions to the standard library, these are two different TS. The Library Fundamentals TS proposes these additions:

• system_error
• apply for tuples
• searchers such as boyer-moore and boyer-moore-horspool [recent blogpost on this in boost]
• std::optional
• std::any
• std::string_view
• various additions to <memory> such as polymorphic allocators
• lots more small additions and improvements

This might be already on its way to C++17 in Jacksonville, even if not, its likely to be added later.

Extensions for Library Fundamentals (aka Library Fundamentals 2) [early draft]

The second part of adding more to the standard library, this document also seems to contain the content of the above TS. This TS includes the following additions:

• erased_type - placeholder type for when the actual type is determined at runtime
• void_t
• propagate_const
• Numerics: GCD / LCM
• Reflection
  
  • source location - __LINE__ and __FILE__ wrapped in a class
  • There are a few reflection papers submitted, so maybe some progress towards reflection in C++?

Concepts TS [final draft]

Also has been covered in the first part, its highly likely to be an edge case in Standardization, the current meeting will maybe show more on this. Its a very popular feature that could be part of C++17.

And more?

And that it is already. There are a few more TS in their very early stage, also Modules, but I'd like to cover this in the next post. A very good overview gives you also Michael Wongs posting about what might go into C++17 and his expectations for the C++ committee meeting in Jacksonville. Also cppreference.com has a good overview over the Technical Specifications.

Join the Meeting C++ patreon community!
This and other posts on Meeting C++ are enabled by my supporters on patreon!