Final features for C++17

In recent weeks, the C++ Committee has held a meeting in Oulu, where the final features of C++17 have been determined and it is about to become an international standard. After the last meeting in Jacksonville, I didn’t have high hopes that C++17 would bring big surprises, but the Oulu meeting worked hard to add some to the new C++17 standard. Important and interesting feature. The Reddit page provides a good overview of C++17 features, and Herb Sutter also gave a good insight into C++17 features in a recent CppCast site (and in his trip report). In addition, Michael Wong gives us a more complete overview of C++17 features.

Let’s talk about the important things first

As I said before, the meeting in Jacksonville After the meeting, many features of C++17 have been very clear. I wrote a three-part blog series offering some advice on whether to move to C++17. We will enter a new century of C++, and relevant standards will be released together with powerful technical specifications, which will become part of the next generation of C++ standards. This means that non-C++17 features (such as Concepts or Modules) will be available as plugins in upcoming compiler releases. Visual Studio currently provides modules, but GCC is the first compiler to support concept. Clang also supports modules, and both Visual Studio and Clang will soon implement module TS-based specifications.

And, I'm thinking, the next two meetings will be mainly dealing with some of the comments, feedback, and issues raised by the various national groups (aka ISO member delegations) . The C++ standard will not add new content, but will have some more or less changes. But I still hope that all these features will pass in the final review.

The final highlights of C++17

##std::variant

Let’s start with what surprised me the most: the variations. Yes, seriously, C++17 brings std::variant. This is awesome and paves the way for future features based on variants and other related ideas. For example, style matching, there's a really good talk on this in C++. According to David Sankel, std::variant is designed after boost::variant and/or other variant libraries. Has a very similar API to boost::variant

variant<int, float> v, w;
v = 12;int i = get<int>(v);
w = get<int>(v);
w = get<0>(v); // same effect as the previous linew = v; // same effect as the previous lineget<double>(v); // ill formedget<3>(v); // ill formedtry {
  get<float>(w); // will throw.}catch (bad_variant_access&) {}

It's great to see this feature included in the C++17 standard instead of using TS detour.

if constexpr(expression)

This is the C++ version of static if (almost). For me this was one of the highlights of Jacksonville, and at the time, that didn't make it so popular. Living up to expectations, it passed Oulu's final review of C++17. With it, C++ can easily make certain blocks of statements compile if, during compilation, a constexpr evaluates to true:

if constexpr (std::is_integer ...) 
{ //integerstuff }
else if constexpr (std::is_floating_point ...) 
{ //floatingpointstuff }
else { // NaN ;) }

This example illustrates this explicitly Yes, constexpr must be judged to be true during compilation, but it has no effect on static_assert. Unselected static_asserts in the statement block will still trigger. This is inappropriate for the standard.

Another interesting point: this feature is written as if constexpr, but the standard spelling still names it constexpr if, but defines it as if constexpr.

Using auto in templates

For C++14, anonymous expressions can use auto to define generic Type parameters. Currently, auto can also be used to define (non-type) template parameters. This makes writing template code easier because auto is shorter than class or typename. You can also use auto to define variable-length template parameters, for example: template6b4b5c6a4dca2aea2d2f974ee580bfa1.

Structured binding

Until now, a famous trick is still used, which is to use std at will ::tie to directly assign a tuple or pair of distinct variables without having to manually deal with the result type. This is a trick, and the variable must exist. Now you can declare the variable and initialize it in one line:

auto [a , b , c] = getvalues();

The brackets cannot be missing, and getvalues ​​returns a tuple. There is no mention of std::pair in the recommendation, so it is not clear whether using pair will also work properly, it is returned by STL in some insert methods.

if and switch with initialization

Now variables can be defined in the if statement: if(int x = 42; true != false), which can be combined with the previous suggestions. Variables defined in an if statement are also valid in its else part. I remember modern C++ design suggesting a trick like curly braces to achieve this, but that was just for a single variable.

It is interesting to use this case, such as locking in if or switch, all the status codes returned by these functions can now be handled inside the if. Essentially, this is equivalent to writing { var x = value; if(...){}else{}} .

More

This is not all, for example, for the improvement of copy ellision (copy removal), the std[0-9]+ namespace is reserved for future standards. Also, there are many interesting discussions and opinions about reddit.

The C++ 17 standard is gradually developing and improving, and standardized tools have also matured and been put into use. This is the biggest gain for C++. Those who want to contribute to the next C++ standard may want to start making plans now. The standardization of C++ has always been promoted by volunteers. There is no money to do this, and everyone is basically someone whose daily work is related to C++. I suggest you take a look at isocpp.org, which has a very nice and detailed introduction. There are also various mailing lists and working groups for you to join.

The above is the content of the final features of C++17. For more related content, please pay attention to the PHP Chinese website (www.php.cn)!