C++17 - What's New in the Core Language?

C++11, C++14, and C++17. I guess, you see the pattern.  Later this year, we will get a new C++ standard. In March 2017, the C++17 specification reached the Draft International Standard stage. Before I dive into the details, I will give you an overview of C++17.

Let me first look at the big picture.

The big picture

Concerning C++98 to C++14, I only mentioned the big points. But, there is a C++ standard missing in my graphic: C++03. This is intentional because C++03 is a very small C++ standard. More like a bug-fix release to C++98. If you know C++, you know, that the first ISO standard C++98 and the ISO standard C++11 are big standards. That will not hold for C++14 and in particular for C++03.

So the question is. Is C++17 a big C++ standard or a small one? From my perspective, the answer is quite easy. C++17 is something in between C++14 and C++11. So, C++17 is neither big nor small. Why? Here comes my short answer.

Overview

C++17 has a lot to offer. That will hold for the core language and the library. Let's first look at the core language.

Core language

Fold expressions

C++11 supports variadic templates. These are templates that can accept an arbitrary number of arguments. The arbitrary number is held by a parameter pack. Additionally, with C++17 you can directly reduce a parameter pack with a binary operator:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

// foldExpressionAll.cpp

#include <iostream>

template<typename... Args>
bool all(Args... args) { return (... && args); }

int main(){

  std::cout << std::boolalpha;

  std::cout << "all(): " << all() << std::endl;
  std::cout << "all(true): " << all(true) << std::endl;
  std::cout << "all(true, true, true, false): " << all(true, true, true, false) << std::endl;

  std::cout << std::endl;

}

 The binary operator is the logical AND in line 6. Here is the output of the program.

That's all I have to say about fold expression because I have already written a post about fold expressions. So, there you have the details.

We stay at compile time.

constexpr if

constexpr if enables it to conditionally compile source code.

1
2
3
4
5
6
7

template <typename T>
auto get_value(T t) {
    if constexpr (std::is_pointer_v<T>)
        return *t; // deduces return type to int for T = int*
    else
        return t;  // deduces return type to int for T = int
}

If T is a pointer, the if branch in line 3 will be compiled. If not, the else branch in line 5. Two points are important to mention. The function get_value has two different return types and both branches of the if the statement has to be valid.

Consequently, what is possible with for statements is with C++17 possible with if and switch statements.

Initializers in if and switch statements

You can directly initialize your variable inside the if and switch statement.

1
2
3
4
5
6
7
8
9

std::map<int,std::string> myMap;

if (auto result = myMap.insert(value); result.second){
    useResult(result.first);  
    // ...
} 
else{
    // ...
} // result is automatically destroyed

Therefore, the variable result is valid inside the if and else branch of the if statement. But result will not pollute the outer scope.

If you use the initializer in if and switch statements in combination with the structured binding declaration, the C++ syntax will be more elegant.

Structured binding declarations

Thanks to the structured binding, you can bind a std::tuple or a struct directly to variables. Therefore I can still improve my last example.

1
2
3
4
5
6
7
8
9

std::map<int,std::string> myMap;
                
if (auto [iter, succeeded] = myMap.insert(value); succeeded) {
    useIter(iter);  
    // ...
}
else{
    // ...
} iter and succeded are automatically be destroyed

auto [iter, succeeded] in line 3 automatically creates the two variables iter and succeeded. They will be destroyed at line 9.

One of these features that make programming less cumbersome. The same holds for template deduction of constructors.

Template deduction of constructors

A function template can deduce its type parameters from its function arguments. But that was not possible for a special function template: the constructor of a class template. With C++17, this statement is simply wrong. A constructor can deduce its type parameters from its constructor arguments.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

// templateArgumentDeduction.cpp

#include <iostream>

template <typename T>
void showMe(const T& t){
  std::cout << t << std::endl;
}

template <typename T>
struct ShowMe{
  ShowMe(const T& t){
    std::cout << t << std::endl;
  }
};

int main(){
  
  std::cout << std::endl;
    
  showMe(5.5);          // not showMe<double>(5.5);
  showMe(5);            // not showMe<int>(5);
    
  ShowMe<double>(5.5);  // with C++17: ShowMe(5.5);
  ShowMe<int>(5);       // with C++17: ShowMe(5);
  
  std::cout << std::endl;
    
}

Line 11 and line 22 are possible in C++ since the first C++ standard. Line 24 and 25 will be possible with C++17. Hence, you do have not to use angle brackets to instantiate a class template.

There is not just usability. Additionally, we will get performance features.

Guaranteed copy elision

RVO stands for Return Value Optimisation and means, that the compiler is allowed to remove unnecessary copy operations. What was until now a possible optimization step, becomes in C++17 a guarantee.

1
2
3
4

MyType func(){
  return MyType{};         // no copy with C++17
}
MyType myType = func();    // no copy with C++17

Two unnecessary copy operations can happen in these few lines. The first one in line 2 and the second one in line 4. With C++17, both copy operations must go. 

If the return value has a name, we call it NRVO. Maybe, you guessed it. This acronym stands for Named Return Value Optimization.

1
2
3
4
5

MyType func(){
  MyType myVal;
  return myVal;            // one copy allowed 
}
MyType myType = func();    // no copy with C++17

The subtle difference is that the compiler can still copy the value myValue according to C++17 (line 3). But no copy will take place in line 5.

If a feature is not necessary anymore or its application is even dangerous, you should remove it. This will happen in C++17 with std::auto_ptr and trigraphs.

auto_ptr and trigraphs removed

auto_ptr

std::auto_ptr is the first smart pointer in C++. Its job is to take care of one resource. But it had a big issue. If you copy a std::auto_ptr, a move operation will take place under the hood. That is the reason, we get std::unique_ptr with C++11 as the replacement. You can not copy a std::unique_ptr.

1
2
3
4
5
6

std::auto_ptr<int> ap1(new int(2011));
std::auto_ptr<int> ap2= ap1;              // OK     (1)

std::unique_ptr<int> up1(new int(2011));
std::unique_ptr<int> up2= up1;            // ERROR  (2)
std::unique_ptr<int> up3= std::move(up1); // OK     (3)

Trigraphs

Trigraphs are a sequence of three characters in the source code that are treated as if they are a single character. They will be necessary if your keyboard doesn't support the single characters.

If you want to write obfuscated code C++17 maybe not be your language anymore.

1
2
3
4
5
6
7

// trigraphs.cpp

int main()??<

  ??(??)??<??>();

??>

I guess, you know, what the program is doing? If not, you have to translate the trigraphs to their single-character representation.

If you apply the table, you will solve the riddle. The program represents a lambda function that will be executed just in place.

1
2
3
4
5
6
7

// trigraphsLambda.cpp

int main(){

  []{}();

}

What's next?

That is easy. In the next post, I write about the library feature, we get with C++17. These are the string_view, the parallel STL, and the filesystem library. Additionally, we will get the new data types std::any, std::optional, and std::variant.