What changes will C ++ 17 bring about?

What changes will C ++ 17 bring about?

This is the third part of my article on proposals at the current C ++ Committee meeting in erbana. This is all about the sub-group change. I have written many articles on this, so this is only the first part. The previous sections are about concurrency, and the second section is about core, network, model, and undefined behavior.

Change

N4126-explicit default comparison operator

This proposal has been mentioned in the reflection section in the previous section, where we use reflection and std: tie to solve this problem. This proposal is intended to make = default legal. for all operators (>, <, = ,! = ,...). These operators are still implemented using the youyuan method, as shown in the following example:

 
 

  
  
class Thing 
  
  
{ 
  
  
    int a, b; 
  
  
public: 
  
  
    // ... 
  
  
    friend bool operator<(const Thing&, const Thing&) = default; 
  
  
    friend bool operator>(const Thing&, const Thing&) = default; 
  
  
    friend bool operator<=(const Thing&, const Thing&) = default; 
  
  
    friend bool operator>=(const Thing&, const Thing&) = default; 
  
  
}; 
 
 

N4127-resolution condition after check

Because a range of for (ranged-for) loops has been proposed, this proposal is transferred to auto and the default type. if the type is not provided, it also wants to introduce or use the for syntax with a range in other statements to make it legal, such as the if statement:

 
 

  
  
std::weak_ptr<foo> wp; 
  
  
if(x: wp.lock()) 
 
 

For C ++, this is a huge change, and not everyone likes it. In particular, the compiler creator has to deal with the scope of the impact. however, if the Committee recognizes a range of for loops in the next version, in other C ++ control structures, such as if, while,, it makes sense to allow the same syntax.

N4131-explicit should never be implicit

This article corresponds to N4074, which argues about the proposed changes, that is, it is wrong to explicitly return {expr}, because explicit should never be implicit. for more details about the draft, the author even gave an example saying that the N4074 proposal may lead to undefined behavior.

N4135-language support for runtime verification (Revised 8)

The author provides a good overview:

If you are careful enough, you can create a database that is essentially defect-free. however, even the best database may have disastrous consequences if used improperly. actual Application of runtime validation according to regulations: When a function is called, the process of checking the prefix condition helps to detect misuse in early tests. it also helps increase the development speed and enhance the robustness of the software. extended validation as required into the development phase, not just the early test phase, will bring more long-term benefits.

N4147-inline variable or encapsulation expression

The author once again provides a good overview:

Inline functions provide appropriate behavior for interfaces that cannot expose objects externally. although it is an unnatural sample, we usually encourage users to use them to wrap global variables. other workarounds include static data members of the class, enumeration, macros, and variable templates, all of which have strange syntax or defects that limit applicability. this proposal specifies the inline identifier in the variable definition, which means that the semantics is similar to the evaluation and link of inline functions. more general, this provides a tool for named values or non-persistent variables that can replace or supplement various workarounds.

N4148-inaccessible operators from the easy-to-copy type are not allowed

Currently, trivially copyable type has a defect: it is equally valid for inaccessible/deleted copy/mobile constructors and value assignment operators. an easy-to-copy object can also be copied by Using std: memcpy, especially when an easy-to-copy object array exists, which is superior in performance. however, it is unwise to do so for a deleted/inaccessible copy/move constructor or value assignment operator. the author proposes to update the wording in the standard and improve features so that std: is_trivially_copyable will return errors for inaccessible/deleted copy/move constructors and operators.

N4149-clear and appropriate class

This article also provides a good overview:

Some classes only work in some contexts: scope guard is usually useless as a sub-expression, and The placeholder of the expression template as a local variable will also have problems. the result of an unused function may mean that the caller will use different protocols, such as std: async. this proposal expands the declaration of classes to prevent such errors, and adds the technology to automatically solve them by replacing the types, such as the value type of an expression template. in addition, the generation of non-movable objects becomes easier to process. The added features include the one mentioned in the "automatic evaluation" proposal, which is more expressive, widely applied, and easy to accept and use.

N4150-alias set attributes: alias semantics similar to restrict in C ++

This proposal would like to add the restrict modifier to C ++ because it already exists in C99 and Some compilers have provided restrict as a C ++ extension. Since there is no restrict modifier defined at present, the author seeks to define how to use it correctly, especially in C ++ 11 like lambda.

N1_2-uncaptured exceptions

This article aims to improve the availability of std: uncaught_exception:

The int std: uncaught_exceptions () function returns the number of exception objects. These objects have been initialized and thrown or re-thrown, but no handler is activated.

N00004-operator assertions

This proposal aims to make assert a language structure, rather than a macro definition:

The assert macro definition never acts like a real function. In the foreseeable future, it will be more like an operator. macro-defined representations in C prevent optimization in the production mode, but allow any side effects in the debugging mode. adding assert as a keyword and built-in operator will produce benefits without any side effects.

N4160-value Constraint

This article analyzes how to support the contract programming style features in C ++. it tries to provide an overview about how to support contracts during compilation rather than runtime checks. the author defines the scope of the document as follows:

Since [N1962] is a fairly complete proposal to add contractual programming support in C ++, this document provides the scope of the issue rather than a specific proposal. we focus on identifying expectations, potential implementation difficulties and costs.

Other contractual programming proposals we know-[N4075], [N4110]-are built on a hypothesis. that is, the support of preconditions must provide some form: Evaluate the preconditions before a function call, occasionally cancel the evaluation of the preconditions, and install the handler for non-fulfillment of the contract. in this article, we will not take this assumption for granted. runtime support is only a subset of our analysis scope. we have carefully explored an optional solution: focusing on static analysis.

N4164-forward reference

As a formal general reference, the type T & always right value (r-value) references, except as a template parameter or using the auto keyword. Technically, it is still a right-value reference, but in this case, the performance is very different. So far, standards do not recognize this. The author wants to introduce this term forward reference (forwarding reference), about the right value reference in the template and auto keywords.

N4165-Unified Call syntax

The call syntax of the member function is x. f () or x-> f (), rather than f (x ). this is a problem in generic programming code, because there is no unified calling syntax, and generic programming code must decide whether to call a member function or a non-member function.

To solve this problem, the author proposes to allow the syntax x./-> f () to call a free function if the first parameter of the function is a pointer or reference of x. This well satisfies the usage of C. When the first pointer parameter of a function is a struct. The authors use FILE * And fseek as examples.

N4166-Removable initialization list

Currently, std: initializer_list is not movable and is designed prior to the importance of mobile semantics. at the same time, it seems sufficient to provide only the copy semantics at that time, but today's situation has changed. the author proposes a templated version of std: intializer_list, which inherits from the non-Right Value of intializer_list type:

 
 

  
  
template< typename T > 
  
  
struct initializer_list< T && > 
  
  
  : initializer_list< T > { 
 
 

This structure implements ownership and mobile semantics.

N1_2-named Parameters

The syntax for naming parameters looks similar to the proposed "for (ranged-for) loop. But under the syntax expression, the two have different meanings. During a function call, you can assign values to the named parameters as in the following example:

 
 

  
  
void foo(int x, int y, int z); 
  
  
foo(40,z: 30, y:20); 
 
 

In this example, the value of z is 30 and the value of x is 40. In addition, non-named parameters cannot be placed after the named parameters.

N1_3-vertex Operator

This article also provides a good overview:

This proposal allows users to define vertex operators (operators. (), so that we can provide "smart reference" similar to "smart pointer ". the main point of this proposal is that if Class Ref defines the operator. (). By default, every operation on the Ref object is in the operator. () before the result. in any case, the operations explicitly declared as Ref member functions do not need to be prefixed when applied to the Ref object. programmers can declare operators. () is private to prevent the pointer pointing to a referenced object from "penetrating" into a larger program.

N00004-call Syntax: x. f (y) vs. f (x, y)

This is similar to the N4165-Unified Call syntax. Simple Description:

The basic suggestion is to define x. f (y) and f (x, y) are equivalent. in addition, to increase compatibility and adequacy, we recommend that you ignore the possibility of uncallable and inaccessible member functions when querying member functions (or function objects ,.

N00005-Comparison of system settings

This document extensively discusses the predefined comparison in C ++ and Its Significance in setting the comparison operator to the default value. This article is closely related to N4126 and also corresponds to N4239.

N00006-Thoughts on Comparison

Bjarne summarizes the following discussion about preset comparison:

This is an excerpt from the partial discussion of the system preset comparison draft. It has made many proposals and made comparisons based on a series of standards. I will make comments on the selection of comparative criteria especially interested in deliberate deutation ).