Final characteristics of the c++17

In recent weeks, the C + + committee met at Oulu (Oulu), where the final features of C++17 were determined and it was about to become an international standard. After the last meeting of Jacksonville (Jacksonville), I did not have much hope that c++17 could bring a great surprise, but Oulu the meeting was trying to add some important and interesting features to the new C++17 standard. The Reddit page provides a good overview of c++17 features, and Herb Sutter a good insight into Cppcast features at the nearest c++17 site (and his itinerary). In addition, Michael Wong gives us a more complete overview of the c++17 features.

First of all, important.

As I said earlier, many of the features of c++17 have been very clear after the meeting held at Jacksonville (Jacksonville). I wrote a series of three-part blog articles about whether to turn to c++17 and made some suggestions. We will enter the new century of C + +, and with the strong technical specifications issued together with the relevant standards, these will become the next generation of C + + standard components. This means that non-c++17 features (for example, concepts or modules ideas) will be used as plug-ins in the upcoming compiler. Visual Studio currently provides modules, and GCC is the first compiler to support concept. Clang also supports modules, and Visual Studio and Clang will soon implement the module TS-based specification.

Furthermore, I am thinking that the next two meetings will deal mainly with comments, feedback and questions raised by various national groups (also known as ISO member delegations). The C + + standard will not add new content, but will have some more or less changes. However, it is hoped that all of these features will be approved in the final review.

The final highlight of c++17

Std::variant (variant)

Let's start with the one that surprises me the most: variants. Yes, seriously, C++17 brought std::variant. This is great and paves the way for future features based on variants and other related ideas. For example, style matching, C + + has a very good conversation about this. According to David Sankel, Std::variant is designed according to Boost::variant and other variant libraries. A very similar API to the 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);//would throw.} catch (bad_variant_access&) {}

Can see this feature included in the C++17 standard, rather than using TS Detour, very happy.

If constexpr (expression)

This is the C + + version of static if (almost). For me it was one of the highlights of Jacksonville, when it was not used. Not to disappoint, it passed the final review of Oulu for C++17. With it, if a constexpr is evaluated as true during the compilation process, C + + can easily compile some statement blocks:

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

This example shows explicitly that constexpr must be judged to be true in the compilation, but has no effect on static_assert. Static_assert that are not selected in the statement block will still be triggered. This is not appropriate for the standard.

There is another interesting place: This feature is written as if constexpr, but the standard spelling still names it as constexpr if, but it is defined for if constexpr.

Use Auto in templates

For c++14, an anonymous expression can use Auto to define a generic parameter. The currently defined (non-type) template parameters are also available with auto. This makes it easier to write template code because auto is shorter than class or typename. You can also use auto, such as:template<auto...a>, to define variable-length template parameters.

Structured bindings

Until now, a well-known trick is to use Std::tie to directly assign a tuple or a pair of different variables without having to handle the result type manually. This is a trick, and the variable must exist, and now you can declare the variable in a row and initialize it:

Auto [A, b, c] = GetValues ();

Parentheses are not small, getvalues returns a tuple. STD::p Air is not mentioned in the recommendation, so it is not clear that using the pair will work, and it is returned by the STL in some insert methods.

If and switch and initialize

You can now define a variable in the IF statement: if (int x = A, true! = False), which can be combined with the previous recommendation. A variable defined in an If statement is also valid in its else section. I remember that modern C + + design has prompted the use of curly braces as a technique to implement this function, but this is only a single variable.

It is interesting to use this case, for example, to lock in if or switch, and all of the status codes returned by these functions can now be processed inside the IF. Essentially, this is equivalent to writing {var x = value; {}else{}}.

More

This is not all, for example, to copy ellision (copy removal) improvements, preserving the std[0-9]+ namespace for future standards. Also, there are many interesting discussions and opinions about Reddit's view.

The C + + 17 standard is being developed gradually and standardized tools have matured and put into use. This is the biggest gain for C + +. Those who want to contribute to the next C + + standard may have to start making plans now. C + + standardization has been driven by volunteers, do this thing without money to take, we are basically some daily work and C + + related people. We recommend that you take a look at isocpp.org, which has very nice and detailed introductions, as well as a variety of mailing lists (mailing lists) and working groups for everyone to join.

The above is the final characteristics of c++17 content, more relevant content please pay attention to topic.alibabacloud.com (www.php.cn)!

