mirror of
https://github.com/changkun/modern-cpp-tutorial.git
synced 2025-12-16 20:27:08 +03:00
book: typo and grammar fixes (#185)
This commit is contained in:
Nikhil Garuda
@@ -13,33 +13,33 @@ order: 0
|
||||
C++ user group is fairly large. From the advent of C++98 to the official finalization of C++11, it has accumulated over a decade. C++14/17 is an important complement and optimization for C++11, and C++20 brings this language to the door of modernization. The extended features of all these new standards are given to the C++ language. Infused with new vitality.
|
||||
C++ programmers, who are still using **traditional C++** (this book refers to C++98 and its previous C++ standards as traditional C++), may even amazed by the fact that they are not using the same language while reading modern C++ code.
|
||||
|
||||
**Modern C++** (this book refers to C++11/14/17/20) introduces a lot of features into traditional C++, which makes the whole C++ become language that modernized. Modern C++ not only enhances the usability of the C++ language itself, but the modification of the `auto` keyword semantics gives us more confidence in manipulating extremely complex template types. At the same time, a lot of enhancements have been made to the language runtime. The emergence of Lambda expressions has made C++ have the "closure" feature of "anonymous functions", which is almost in modern programming languages (such as Python/Swift/.. It has become commonplace, and the emergence of rvalue references has solved the problem of temporary object efficiency that C++ has long been criticized.
|
||||
**Modern C++** (this book refers to C++11/14/17/20) introduces a lot of features into traditional C++, which makes the whole C++ become a language that modernized. Modern C++ not only enhances the usability of the C++ language itself, but the modification of the `auto` keyword semantics gives us more confidence in manipulating extremely complex template types. At the same time, a lot of enhancements have been made to the language runtime. The emergence of Lambda expressions has made C++ have the "closure" feature of "anonymous functions", which is almost in modern programming languages (such as Python, Swift, etc). It has become commonplace, and the emergence of rvalue references has solved the problem of temporary object efficiency that C++ has long been criticized for.
|
||||
|
||||
C++17 is the direction that has been promoted by the C++ community in the past three years. It also points out an important development direction of **modern C++** programming. Although it does not appear as much as C++11, it contains a large number of small and beautiful languages and features (such as structured binding), and the appearance of these features once again corrects our programming paradigm in C++.
|
||||
|
||||
Modern C++ also adds a lot of tools and methods to its own standard library, such as `std::thread` at the level of the language itself, which supports concurrent programming and no longer depends on the underlying system on different platforms. The API implements cross-platform support at the language level; `std::regex` provides full regular expression support and more. C++98 has been proven to be a very successful "paradigm", and the emergence of modern C++ further promotes this paradigm, making C++ a better language for system programming and library development. Concepts provide verification on the compile-time of template parameters, further enhancing the usability of the language.
|
||||
Modern C++ also adds a lot of tools and methods to its standard library, such as `std::thread` at the level of the language itself, which supports concurrent programming and no longer depends on the underlying system on different platforms. The API implements cross-platform support at the language level; `std::regex` provides full regular expression support and more. C++98 has been proven to be a very successful "paradigm", and the emergence of modern C++ further promotes this paradigm, making C++ a better language for system programming and library development. Concepts verify the compile-time of template parameters, further enhancing the usability of the language.
|
||||
|
||||
In conclusion, as an advocate and practitioner of C++, we always maintain an open mind to accept new things, and we can promote the development of C++ faster, making this old and novel language more vibrant.
|
||||
|
||||
## Targets
|
||||
|
||||
- This book assumes that readers are already familiar with traditional C++ (i.e. C++98 or earlier), at least they do not have any difficulty in reading traditional C++ code. In other words, those who have long experience in traditional C++ and people who desire to quickly understand the features of modern C++ in a short period of time are well suited to read the book;
|
||||
- This book assumes that readers are already familiar with traditional C++ (i.e. C++98 or earlier), at least they do not have any difficulty in reading traditional C++ code. In other words, those who have long experience in traditional C++ and people who desire to quickly understand the features of modern C++ in a short period are well suited to read the book;
|
||||
|
||||
- This book introduces to a certain extent of the dark magic of modern C++. However, these magics are very limited, they are not suitable for readers who want to learn advanced C++. The purpose of this book is offering a quick start for modern C++. Of course, advanced readers can also use this book to review and examine themselves on modern C++.
|
||||
- This book introduces to a certain extent of the dark magic of modern C++. However, these magics are very limited, they are not suitable for readers who want to learn advanced C++. The purpose of this book is to offer a quick start for modern C++. Of course, advanced readers can also use this book to review and examine themselves on modern C++.
|
||||
|
||||
## Purpose
|
||||
|
||||
The book claims "On the Fly". Its intent is to provide a comprehensive introduction to the relevant features regarding modern C++ (before 2020s).
|
||||
The book claims "On the Fly". It intends to provide a comprehensive introduction to the relevant features regarding modern C++ (before the 2020s).
|
||||
Readers can choose interesting content according to the following table of content to learn and quickly familiarize the new features you would like to learn.
|
||||
Readers should aware that all of these features are not required. It should be learnt when you really need it.
|
||||
Readers should aware that all of these features are not required. It should be learned when you need it.
|
||||
|
||||
At the same time, instead of grammar-only, the book introduces the historical background as simple as possible of its technical requirements, which provides great help in understanding why these features comes out.
|
||||
At the same time, instead of grammar-only, the book introduces the historical background as simple as possible of its technical requirements, which provides great help in understanding why these features come out.
|
||||
|
||||
In addition, The author would like to encourage that readers should be able to use modern C++ directly in their new projects and migrate their old projects to modern C++ gradually after read the book.
|
||||
Also, the author would like to encourage that readers should be able to use modern C++ directly in their new projects and migrate their old projects to modern C++ gradually after reading the book.
|
||||
|
||||
## Code
|
||||
|
||||
Each chapter of this book has a lot of code. If you encounter problems when writing your own code with the introductory features of the book, you might as well read the source code attached to the book. You can find the book [here](../../code). All the code organized by chapter, the folder name is the chapter number.
|
||||
Each chapter of this book has a lot of code. If you encounter problems when writing your own code with the introductory features of the book, you might as well read the source code attached to the book. You can find the book [here](../../code). All the code is organized by chapter, the folder name is the chapter number.
|
||||
|
||||
## Exercises
|
||||
|
||||
@@ -49,4 +49,4 @@ There are few exercises At the end of each chapter of the book. It is for testin
|
||||
|
||||
## Licenses
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
|
||||
@@ -8,7 +8,7 @@ order: 1
|
||||
|
||||
[TOC]
|
||||
|
||||
**Compilation Environment**: This book will use `clang++` as the only compiler used,
|
||||
**Compilation Environment**: This book will use `clang++` as the only compiler used,
|
||||
and always use the `-std=c++2a` compilation flag in your code.
|
||||
|
||||
```bash
|
||||
@@ -21,15 +21,15 @@ InstalledDir: /Library/Developer/CommandLineTools/usr/bin
|
||||
|
||||
## 1.1 Deprecated Features
|
||||
|
||||
Before learning modern C++, let's take a look at the main features that have been deprecated since C++11:
|
||||
Before learning modern C++, let's take a look at the main features that have deprecated since C++11:
|
||||
|
||||
> **Note**: Deprecation is not completely unusable, it is only intended to imply that features will disappear from future standards and should be avoided. However, the deprecated features are still part of the standard library, and most of the features are actually "permanently" reserved for compatibility reasons.
|
||||
> **Note**: Deprecation is not completely unusable, it is only intended to imply that features will disappear from future standards and should be avoided. But, the deprecated features are still part of the standard library, and most of the features are actually "permanently" reserved for compatibility reasons.
|
||||
|
||||
- **The string literal constant is no longer allowed to be assigned to a `char *`. If you need to assign and initialize a `char *` with a string literal constant, you should use `const char *` or `auto`.**
|
||||
|
||||
```cpp
|
||||
char *str = "hello world!"; // A deprecation warning will appear
|
||||
```
|
||||
```cpp
|
||||
char *str = "hello world!"; // A deprecation warning will appear
|
||||
```
|
||||
|
||||
- **C++98 exception description, `unexpected_handler`, `set_unexpected()` and other related features are deprecated and should use `noexcept`.**
|
||||
|
||||
@@ -47,11 +47,11 @@ Before learning modern C++, let's take a look at the main features that have bee
|
||||
|
||||
- ... and many more
|
||||
|
||||
There are also other features such as parameter binding (C++11 provides `std::bind` and `std::function`), `export`, and etc. are also deprecated. These features mentioned above **If you have never used or heard of it, please don't try to understand them. You should move closer to the new standard and learn new features directly**. After all, technology is moving forward.
|
||||
There are also other features such as parameter binding (C++11 provides `std::bind` and `std::function`), `export` etc. are also deprecated. These features mentioned above **If you have never used or heard of it, please don't try to understand them. You should move closer to the new standard and learn new features directly**. After all, technology is moving forward.
|
||||
|
||||
## 1.2 Compatibilities with C
|
||||
|
||||
For some force majeure and historical reasons, we had to use some C code (even old C code) in C++, for example, Linux system calls. Before the advent of modern C++, most people talked about "what is the difference between C and C++". Generally speaking, in addition to answering the object-oriented class features and the template features of generic programming, there is no other opinion, or even a direct answer. "Almost" is also a lot of people. The Venn diagram in Figure 1.2 roughly answers the C and C++ related compatibility.
|
||||
For some force majeure and historical reasons, we had to use some C code (even old C code) in C++, for example, Linux system calls. Before the advent of modern C++, most people talked about "what is the difference between C and C++". Generally speaking, in addition to answering the object-oriented class features and the template features of generic programming, there is no other opinion or even a direct answer. "Almost" is also a lot of people. The Venn diagram in Figure 1.2 roughly answers the C and C++ related compatibility.
|
||||
|
||||
|
||||
|
||||
@@ -121,7 +121,7 @@ clean:
|
||||
rm -rf *.o $(TARGET)
|
||||
```
|
||||
|
||||
> Note: Indentation in `Makefile` is a tab instead of a space character. If you copy this code directly into your editor, the tab may be automatically replaced. Please ensure the indentation in the `Makefile`. It is done by tabs.
|
||||
> **Note**: Indentation in `Makefile` is a tab instead of a space character. If you copy this code directly into your editor, the tab may be automatically replaced. Please ensure the indentation in the `Makefile` is done by tabs.
|
||||
>
|
||||
> If you don't know the use of `Makefile`, it doesn't matter. In this tutorial, you won't build code that is written too complicated. You can also read this book by simply using `clang++ -std=c++2a` on the command line.
|
||||
|
||||
|
||||
@@ -92,12 +92,11 @@ We will discuss them in detail later in the [decltype](#decltype) section.
|
||||
|
||||
### constexpr
|
||||
|
||||
C++ itself already has the concept of constant expressions,
|
||||
such as 1+2, 3*4. Such expressions always produce the same result
|
||||
without any side effects. If the compiler can directly optimize
|
||||
and embed these expressions into the program at compile time,
|
||||
it will increase the performance of the program.
|
||||
A very obvious example is in the definition phase of an array:
|
||||
C++ itself already has the concept of constant expressions, such as 1+2,
|
||||
3\*4. Such expressions always produce the same result without any side effects.
|
||||
If the compiler can directly optimize and embed these expressions into the program at
|
||||
compile-time, it will increase the performance of the program. A very obvious example
|
||||
is in the definition phase of an array:
|
||||
|
||||
```cpp
|
||||
#include <iostream>
|
||||
@@ -147,14 +146,14 @@ we need to use the `constexpr` feature introduced in C++11, which will be introd
|
||||
to solve this problem; for `arr_5`, before C++98 The compiler cannot know that `len_foo()`
|
||||
actually returns a constant at runtime, which causes illegal production.
|
||||
|
||||
> Note that most compilers now have their own compiler optimizations.
|
||||
> Note that most compilers now have their compiler optimizations.
|
||||
> Many illegal behaviors become legal under the compiler's optimization.
|
||||
> If you need to reproduce the error, you need to use the old version of the compiler.
|
||||
|
||||
C++11 provides `constexpr` to let the user explicitly declare that the function or
|
||||
object constructor will become a constant expression at compile time.
|
||||
This keyword explicitly tells the compiler that it should verify that `len_foo`
|
||||
should be a compile time constant expression. Constant expression.
|
||||
should be a compile-time constant expression. Constant expression.
|
||||
|
||||
In addition, the function of `constexpr` can use recursion:
|
||||
|
||||
@@ -240,7 +239,7 @@ Initialization is a very important language feature,
|
||||
the most common one is when the object is initialized.
|
||||
In traditional C++, different objects have different initialization methods,
|
||||
such as ordinary arrays, PODs (**P**lain **O**ld **D**ata,
|
||||
ie classes without constructs, destructors, and virtual functions)
|
||||
i.e. classes without constructs, destructors, and virtual functions)
|
||||
Or struct type can be initialized with `{}`,
|
||||
which is what we call the initialization list.
|
||||
For the initialization of the class object,
|
||||
@@ -332,7 +331,7 @@ provided in other languages. In the chapter on containers,
|
||||
we will learn that C++11 has added a `std::tuple` container for
|
||||
constructing a tuple that encloses multiple return values. But the flaw
|
||||
is that C++11/14 does not provide a simple way to get and define
|
||||
the elements in the tuple directly from the tuple,
|
||||
the elements in the tuple from the tuple,
|
||||
although we can unpack the tuple using `std::tie`
|
||||
But we still have to be very clear about how many objects this tuple contains,
|
||||
what type of each object is, very troublesome.
|
||||
@@ -360,7 +359,7 @@ The `auto` type derivation is described in the
|
||||
|
||||
## 2.3 Type inference
|
||||
|
||||
In traditional C and C++, the types of parameters must be clearly defined, which does not help us to quickly encode, especially when we are faced with a large number of complex template types, we must clearly indicate the type of variables in order to proceed. Subsequent coding, which not only slows down our development efficiency, but also makes the code stinking and long.
|
||||
In traditional C and C++, the types of parameters must be clearly defined, which does not help us to quickly encode, especially when we are faced with a large number of complex template types, we must indicate the type of variables to proceed. Subsequent coding, which not only slows down our development efficiency but also makes the code stinking and long.
|
||||
|
||||
C++11 introduces the two keywords `auto` and `decltype` to implement type derivation, letting the compiler worry about the type of the variable. This makes C++ the same as other modern programming languages, in a way that provides the habit of not having to worry about variable types.
|
||||
|
||||
@@ -415,6 +414,7 @@ auto arr = new auto(10); // arr as int *
|
||||
> **Note**: `auto` cannot be used for function arguments, so the following
|
||||
> is not possible to compile (considering overloading,
|
||||
> we should use templates):
|
||||
>
|
||||
> ```cpp
|
||||
> int add(auto x, auto y);
|
||||
>
|
||||
@@ -437,7 +437,6 @@ auto arr = new auto(10); // arr as int *
|
||||
The `decltype` keyword is used to solve the defect that the auto keyword
|
||||
can only type the variable. Its usage is very similar to `typeof`:
|
||||
|
||||
|
||||
```cpp
|
||||
decltype(expression)
|
||||
```
|
||||
@@ -485,9 +484,9 @@ R add(T x, U y) {
|
||||
|
||||
> Note: There is no difference between typename and class in the template parameter list. Before the keyword typename appears, class is used to define the template parameters. However, when defining a variable with [nested dependency type](http://en.cppreference.com/w/cpp/language/dependent_name#The_typename_disambiguator_for_dependent_names) in the template, you need to use typename to eliminate ambiguity.
|
||||
|
||||
Such code is actually very ugly, because the programmer must explicitly
|
||||
Such code is very ugly because the programmer must explicitly
|
||||
indicate the return type when using this template function.
|
||||
But in fact we don't know what kind of operation
|
||||
But in fact, we don't know what kind of operation
|
||||
the `add()` function will do, and what kind of return type to get.
|
||||
|
||||
This problem was solved in C++11. Although you may immediately
|
||||
@@ -583,7 +582,7 @@ decltype(auto) look_up_a_string_2() {
|
||||
|
||||
### if constexpr
|
||||
|
||||
As we saw at the beginning of this chapter, we know that C++11 introduces the `constexpr` keyword, which compiles expressions or functions into constant results. A natural idea is that if we introduce this feature into the conditional judgment, let the code complete the branch judgment at compile time, can it make the program more efficient? C++17 introduces the `constexpr` keyword into the `if` statement, allowing you to declare the condition of a constant expression in your code. Consider the following code:
|
||||
As we saw at the beginning of this chapter, we know that C++11 introduces the `constexpr` keyword, which compiles expressions or functions into constant results. A natural idea is that if we introduce this feature into the conditional judgment, let the code complete the branch judgment at compile-time, can it make the program more efficient? C++17 introduces the `constexpr` keyword into the `if` statement, allowing you to declare the condition of a constant expression in your code. Consider the following code:
|
||||
|
||||
```cpp
|
||||
#include <iostream>
|
||||
@@ -619,7 +618,7 @@ int main() {
|
||||
|
||||
### Range-based for loop
|
||||
|
||||
Finally, C++11 introduces a range-based iterative method, and we have the ability to write loops that are as concise
|
||||
Finally, C++11 introduces a range-based iterative method, and we can write loops that are as concise
|
||||
as Python, and we can further simplify the previous example:
|
||||
|
||||
```cpp
|
||||
@@ -642,7 +641,7 @@ int main() {
|
||||
|
||||
## 2.5 Templates
|
||||
|
||||
C++ templates have always been a special art of the language, and templates can even be used independently as a new language. The philosophy of the template is to throw all the problems that can be processed at compile time into the compile time, and only deal with those core dynamic services at runtime, so as to greatly optimize the performance of the runtime. Therefore, templates are also regarded by many as one of the black magic of C++.
|
||||
C++ templates have always been a special art of the language, and templates can even be used independently as a new language. The philosophy of the template is to throw all the problems that can be processed at compile time into the compile time, and only deal with those core dynamic services at runtime, to greatly optimize the performance of the runtime. Therefore, templates are also regarded by many as one of the black magic of C++.
|
||||
|
||||
### Extern templates
|
||||
|
||||
@@ -697,7 +696,7 @@ typedef MagicType<std::vector<T>, std::string> FakeDarkMagic;
|
||||
|
||||
C++11 uses `using` to introduce the following form of writing, and at the same time supports the same effect as the traditional `typedef`:
|
||||
|
||||
> Usually we use `typedef` to define the alias syntax: `typedef original name new name; `, but the definition syntax for aliases such as function pointers is different, which usually causes a certain degree of difficulty for direct reading.
|
||||
> Usually, we use `typedef` to define the alias syntax: `typedef original name new name; `, but the definition syntax for aliases such as function pointers is different, which usually causes a certain degree of difficulty for direct reading.
|
||||
|
||||
```cpp
|
||||
typedef int (*process)(void *);
|
||||
@@ -746,7 +745,7 @@ and there is no need to fix the number of parameters when defining.
|
||||
template<typename... Ts> class Magic;
|
||||
```
|
||||
|
||||
The template class Magic object can accept unrestricted number of typename as
|
||||
The template class Magic object can accept an unrestricted number of typename as
|
||||
a formal parameter of the template, such as the following definition:
|
||||
|
||||
```cpp
|
||||
@@ -799,7 +798,6 @@ the parameter package, but there are two classic processing methods:
|
||||
|
||||
Recursion is a very easy way to think of and the most classic approach. This method continually recursively passes template parameters to the function, thereby achieving the purpose of recursively traversing all template parameters:
|
||||
|
||||
|
||||
```cpp
|
||||
#include <iostream>
|
||||
template<typename T0>
|
||||
@@ -833,7 +831,7 @@ void printf2(T0 t0, T... t) {
|
||||
|
||||
**3. Initialize list expansion**
|
||||
|
||||
Recursive template functions are a standard practice, but the obvious drawback is that you must define a function that terminates recursion.
|
||||
Recursive template functions are standard practice, but the obvious drawback is that you must define a function that terminates recursion.
|
||||
|
||||
Here is a description of the black magic that is expanded using the initialization list:
|
||||
|
||||
@@ -880,7 +878,7 @@ auto add(T t, U u) {
|
||||
|
||||
The parameters of the template `T` and `U` are specific types.
|
||||
But there is also a common form of template parameter that allows different literals
|
||||
to be template parameters, ie non-type template parameters:
|
||||
to be template parameters, i.e. non-type template parameters:
|
||||
|
||||
```cpp
|
||||
template <typename T, int BufSize>
|
||||
@@ -896,7 +894,7 @@ buffer_t<int, 100> buf; // 100 as template parameter
|
||||
```
|
||||
|
||||
In this form of template parameters, we can pass `100` as a parameter to the template.
|
||||
After C++11 introduced the feature of type derivation, we will naturally ask, since the template parameters here
|
||||
After C++11 introduced the feature of type derivation, we will naturally ask, since the template parameters here.
|
||||
Passing with a specific literal, can the compiler assist us in type derivation,
|
||||
By using the placeholder `auto`, there is no longer a need to explicitly specify the type?
|
||||
Fortunately, C++17 introduces this feature, and we can indeed use the `auto` keyword to let the compiler assist in the completion of specific types of derivation.
|
||||
@@ -1022,7 +1020,7 @@ struct SubClass3: Base {
|
||||
|
||||
### Explicit delete default function
|
||||
|
||||
In traditional C++, if the programmer does not provide it, the compiler will default to generating default constructors, copy constructs, assignment operators, and destructors for the object. In addition, C++ also defines operators such as `new` `delete` for all classes. This part of the function can be overridden when the programmer needs it.
|
||||
In traditional C++, if the programmer does not provide it, the compiler will default to generating default constructors, copy constructs, assignment operators, and destructors for the object. Besides, C++ also defines operators such as `new` `delete` for all classes. This part of the function can be overridden when the programmer needs it.
|
||||
|
||||
This raises some requirements: the ability to accurately control the generation of default functions cannot be controlled. For example, when copying a class is prohibited, the copy constructor and the assignment operator must be declared as `private`. Trying to use these undefined functions will result in compilation or link errors, which is a very unconventional way.
|
||||
|
||||
@@ -1041,7 +1039,7 @@ class Magic {
|
||||
|
||||
### Strongly typed enumerations
|
||||
|
||||
In traditional C++, enumerated types are not type-safe, and enumerated types are treated as integers, which allows two completely different enumerated types to be directly compared (although the compiler gives the check, but not all) , ** Even the enumeration value names of different enum types in the same namespace cannot be the same**, which is usually not what we want to see.
|
||||
In traditional C++, enumerated types are not type-safe, and enumerated types are treated as integers, which allows two completely different enumerated types to be directly compared (although the compiler gives the check, but not all), ** Even the enumeration value names of different enum types in the same namespace cannot be the same**, which is usually not what we want to see.
|
||||
|
||||
C++11 introduces an enumeration class and declares it using the syntax of `enum class`:
|
||||
|
||||
@@ -1085,7 +1083,7 @@ std::cout << new_enum::value3 << std::endl
|
||||
|
||||
This section introduces the enhancements to language usability in modern C++, which I believe are the most important features that almost everyone needs to know and use:
|
||||
|
||||
1. auto type derivation
|
||||
1. Auto type derivation
|
||||
2. Scope for iteration
|
||||
3. Initialization list
|
||||
4. Variable parameter template
|
||||
|
||||
@@ -10,9 +10,9 @@ order: 3
|
||||
|
||||
## 3.1 Lambda Expression
|
||||
|
||||
Lambda expressions are one of the most important features in modern C++, and Lambda expressions actually provide a feature like anonymous functions.
|
||||
Anonymous functions are used when a function is needed, but you don’t want to use name to call a function. There are actually many, many scenes like this.
|
||||
So anonymous functions are almost standard on modern programming languages.
|
||||
Lambda expressions are one of the most important features in modern C++, and Lambda expressions provide a feature like anonymous functions.
|
||||
Anonymous functions are used when a function is needed, but you don’t want to use a name to call a function. There are many, many scenes like this.
|
||||
So anonymous functions are almost standard in modern programming languages.
|
||||
|
||||
### Basics
|
||||
|
||||
@@ -24,22 +24,22 @@ The basic syntax of a Lambda expression is as follows:
|
||||
}
|
||||
```
|
||||
|
||||
The above grammar rules are well understood except for the things in `[capture list]`,
|
||||
The above grammar rules are well understood except for the things in `[capture list]`,
|
||||
except that the function name of the general function is omitted.
|
||||
The return value is in the form of a `->`
|
||||
The return value is in the form of a `->`
|
||||
(we have already mentioned this in the tail return type earlier in the previous section).
|
||||
|
||||
The so-called capture list can be understood as a type of parameter.
|
||||
The internal function body of a lambda expression cannot use variables outside
|
||||
The so-called capture list can be understood as a type of parameter.
|
||||
The internal function body of a lambda expression cannot use variables outside
|
||||
the body of the function by default.
|
||||
At this time, the capture list can serve to transfer external data.
|
||||
According to the behavior passed,
|
||||
At this time, the capture list can serve to transfer external data.
|
||||
According to the behavior passed,
|
||||
the capture list is also divided into the following types:
|
||||
|
||||
#### 1. Value capture
|
||||
|
||||
Similar to parameter passing, the value capture is based on the fact that
|
||||
the variable can be copied, except that the captured variable is copied
|
||||
Similar to parameter passing, the value capture is based on the fact that
|
||||
the variable can be copied, except that the captured variable is copied
|
||||
when the lambda expression is created, not when it is called:
|
||||
|
||||
```cpp
|
||||
@@ -76,13 +76,13 @@ void lambda_reference_capture() {
|
||||
|
||||
#### 3. Implicit capture
|
||||
|
||||
Manually writing a capture list is sometimes very complicated.
|
||||
This mechanical work can be handled by the compiler.
|
||||
At this point, you can write a `&` or `=` to the compiler to
|
||||
Manually writing a capture list is sometimes very complicated.
|
||||
This mechanical work can be handled by the compiler.
|
||||
At this point, you can write a `&` or `=` to the compiler to
|
||||
declare the reference or value capture.
|
||||
|
||||
To summarize, capture provides the ability for lambda expressions
|
||||
to use external values. The four most common forms of
|
||||
To summarize, capture provides the ability for lambda expressions
|
||||
to use external values. The four most common forms of
|
||||
capture lists can be:
|
||||
|
||||
- \[\] empty capture list
|
||||
@@ -92,16 +92,16 @@ capture lists can be:
|
||||
|
||||
#### 4. Expression capture
|
||||
|
||||
> This section needs to understand the rvalue references and smart pointers that
|
||||
> This section needs to understand the rvalue references and smart pointers that
|
||||
> will be mentioned later.
|
||||
|
||||
The value captures and reference captures mentioned above are variables that have been
|
||||
declared in the outer scope, so these capture methods capture the lvalue
|
||||
The value captures and reference captures mentioned above are variables that have been
|
||||
declared in the outer scope, so these capture methods capture the lvalue
|
||||
and not capture the rvalue.
|
||||
|
||||
C++14 gives us the convenience of allowing the captured members to be initialized
|
||||
C++14 gives us the convenience of allowing the captured members to be initialized
|
||||
with arbitrary expressions, which allows the capture of rvalues.
|
||||
The type of the captured variable being declared is judged according to the expression,
|
||||
The type of the captured variable being declared is judged according to the expression,
|
||||
and the judgment is the same as using `auto`:
|
||||
|
||||
```cpp
|
||||
@@ -114,20 +114,20 @@ void lambda_expression_capture() {
|
||||
}
|
||||
```
|
||||
|
||||
In the above code, `important` is an exclusive pointer that cannot be caught by value capture using `=`.
|
||||
At this time we need to transfer it to the rvalue and
|
||||
In the above code, `important` is an exclusive pointer that cannot be caught by value capture using `=`.
|
||||
At this time we need to transfer it to the rvalue and
|
||||
initialize it in the expression.
|
||||
|
||||
### Generic Lambda
|
||||
|
||||
In the previous section we mentioned that the `auto` keyword cannot be used
|
||||
In the previous section, we mentioned that the `auto` keyword cannot be used
|
||||
in the parameter list because it would conflict with the functionality of the template.
|
||||
But Lambda expressions are not ordinary functions, so Lambda expressions are not templated.
|
||||
This has caused us some trouble: the parameter table cannot be generalized,
|
||||
This has caused us some trouble: the parameter table cannot be generalized,
|
||||
and the parameter table type must be clarified.
|
||||
|
||||
Fortunately, this trouble only exists in C++11, starting with C++14.
|
||||
The formal parameters of the Lambda function can use the `auto` keyword
|
||||
The formal parameters of the Lambda function can use the `auto` keyword
|
||||
to generate generic meanings:
|
||||
|
||||
```cpp
|
||||
@@ -135,7 +135,7 @@ void lambda_generic() {
|
||||
auto generic = [](auto x, auto y) {
|
||||
return x+y;
|
||||
};
|
||||
|
||||
|
||||
std::cout << generic(1, 2) << std::endl;
|
||||
std::cout << generic(1.1, 2.2) << std::endl;
|
||||
}
|
||||
@@ -143,15 +143,15 @@ void lambda_generic() {
|
||||
|
||||
## 3.2 Function Object Wrapper
|
||||
|
||||
Although the features are part of the standard library and not found in runtime,
|
||||
Although the features are part of the standard library and not found in runtime,
|
||||
it enhances the runtime capabilities of the C++ language.
|
||||
This part of the content is also very important, so put it here for introduction.
|
||||
This part of the content is also very important, so put it here for the introduction.
|
||||
|
||||
### `std::function`
|
||||
|
||||
The essence of a Lambda expression is an object of a class type (called a closure type)
|
||||
The essence of a Lambda expression is an object of a class type (called a closure type)
|
||||
that is similar to a function object type (called a closure object).
|
||||
When the capture list of a Lambda expression is empty, the closure object
|
||||
When the capture list of a Lambda expression is empty, the closure object
|
||||
can also be converted to a function pointer value for delivery, for example:
|
||||
|
||||
```cpp
|
||||
@@ -170,20 +170,19 @@ int main() {
|
||||
}
|
||||
```
|
||||
|
||||
The above code gives two different forms of invocation, one is to call Lambda
|
||||
as a function type, and the other is to directly call a Lambda expression.
|
||||
In C++11, these concepts are unified.
|
||||
The type of object that can be called is collectively called the callable type.
|
||||
The above code gives two different forms of invocation, one is to call Lambda
|
||||
as a function type, and the other is to directly call a Lambda expression.
|
||||
In C++11, these concepts are unified.
|
||||
The type of object that can be called is collectively called the callable type.
|
||||
This type is introduced by `std::function`.
|
||||
|
||||
C++11 `std::function` is a generic, polymorphic function wrapper
|
||||
whose instances can store, copy, and call any target entity that can be called.
|
||||
It is also an existing callable to C++. A type-safe package of entities (relatively,
|
||||
the call to a function pointer is not type-safe), in other words,
|
||||
a container of functions. When we have a container for functions,
|
||||
C++11 `std::function` is a generic, polymorphic function wrapper
|
||||
whose instances can store, copy, and call any target entity that can be called.
|
||||
It is also an existing callable to C++. A type-safe package of entities (relatively,
|
||||
the call to a function pointer is not type-safe), in other words,
|
||||
a container of functions. When we have a container for functions,
|
||||
we can more easily handle functions and function pointers as objects. e.g:
|
||||
|
||||
|
||||
```cpp
|
||||
#include <functional>
|
||||
#include <iostream>
|
||||
@@ -207,10 +206,10 @@ int main() {
|
||||
|
||||
### `std::bind` and `std::placeholder`
|
||||
|
||||
And `std::bind` is used to bind the parameters of the function call.
|
||||
It solves the requirement that we may not always be able to get all the parameters
|
||||
of a function at one time. Through this function, we can Part of the call parameters
|
||||
are bound to the function in advance to become a new object,
|
||||
And `std::bind` is used to bind the parameters of the function call.
|
||||
It solves the requirement that we may not always be able to get all the parameters
|
||||
of a function at one time. Through this function, we can Part of the call parameters
|
||||
are bound to the function in advance to become a new object,
|
||||
and then complete the call after the parameters are complete. e.g:
|
||||
|
||||
```cpp
|
||||
@@ -226,38 +225,38 @@ int main() {
|
||||
}
|
||||
```
|
||||
|
||||
> **Tip:** Note the magic of the `auto` keyword. Sometimes we may not be familiar
|
||||
> **Tip:** Note the magic of the `auto` keyword. Sometimes we may not be familiar
|
||||
> with the return type of a function, but we can circumvent this problem by using `auto`.
|
||||
|
||||
## 3.3 rvalue Reference
|
||||
|
||||
rvalue references are one of the important features introduced by C++11
|
||||
that are synonymous with Lambda expressions. Its introduction solves
|
||||
rvalue references are one of the important features introduced by C++11
|
||||
that are synonymous with Lambda expressions. Its introduction solves
|
||||
a large number of historical issues in C++.
|
||||
Eliminating extra overhead such as `std::vector`, `std::string`,
|
||||
Eliminating extra overhead such as `std::vector`, `std::string`,
|
||||
and making the function object container `std::function` possible.
|
||||
|
||||
### lvalue, rvalue, prvalue, xvalue
|
||||
|
||||
To understand what the rvalue reference is all about, you must have a clear
|
||||
To understand what the rvalue reference is all about, you must have a clear
|
||||
understanding of the lvalue and the rvalue.
|
||||
|
||||
**lvalue, left value**, as the name implies, is the value to the left of the assignment
|
||||
symbol. To be precise, an lvalue is a persistent object that still exists after
|
||||
**lvalue, left value**, as the name implies, is the value to the left of the assignment
|
||||
symbol. To be precise, an lvalue is a persistent object that still exists after
|
||||
an expression (not necessarily an assignment expression).
|
||||
|
||||
**Rvalue, right value**, the value on the right refers to the temporary object
|
||||
**Rvalue, right value**, the value on the right refers to the temporary object
|
||||
that no longer exists after the expression ends.
|
||||
|
||||
In C++11, in order to introduce powerful rvalue references,
|
||||
the concept of rvalue values is further divided into:
|
||||
In C++11, in order to introduce powerful rvalue references,
|
||||
the concept of rvalue values is further divided into:
|
||||
prvalue, and xvalue.
|
||||
|
||||
**pvalue, pure rvalue**, purely rvalue, either purely literal,
|
||||
such as `10`, `true`; either the result of the evaluation is equivalent to
|
||||
a literal or anonymous temporary object, for example `1+2`.
|
||||
Temporary variables returned by non-references, temporary variables generated
|
||||
by operation expressions, original literals, and Lambda expressions
|
||||
**pvalue, pure rvalue**, purely rvalue, either purely literal,
|
||||
such as `10`, `true`; either the result of the evaluation is equivalent to
|
||||
a literal or anonymous temporary object, for example `1+2`.
|
||||
Temporary variables returned by non-references, temporary variables generated
|
||||
by operation expressions, original literals, and Lambda expressions
|
||||
are all pure rvalue values.
|
||||
|
||||
Note that a string literal became rvalue in a class, and remains an lvalue in other cases (e.g., in a function)：
|
||||
@@ -276,11 +275,11 @@ int main() {
|
||||
}
|
||||
```
|
||||
|
||||
**xvalue, expiring value** is the concept proposed by C++11 to introduce
|
||||
rvalue references (so in traditional C++, pure rvalue and rvalue are the same concept),
|
||||
**xvalue, expiring value** is the concept proposed by C++11 to introduce
|
||||
rvalue references (so in traditional C++, pure rvalue and rvalue are the same concepts),
|
||||
a value that is destroyed but can be moved.
|
||||
|
||||
It would be a little hard to understand the xvalue,
|
||||
It would be a little hard to understand the xvalue,
|
||||
let's look at the code like this:
|
||||
|
||||
```cpp
|
||||
@@ -292,33 +291,33 @@ std::vector<int> foo() {
|
||||
std::vector<int> v = foo();
|
||||
```
|
||||
|
||||
In such code, as far as the traditional understanding is concerned,
|
||||
the return value `temp` of the function `foo` is internally created
|
||||
and then assigned to `v`, whereas when `v` gets this object, the entire `temp` is copied.
|
||||
And then destroy `temp`, if this `temp` is very large, this will cause a lot of extra
|
||||
overhead (this is the problem that traditional C++ has been criticized for).
|
||||
In the last line, `v` is the lvalue, and the value returned by `foo()` is
|
||||
the rvalue (which is also a pure rvalue).
|
||||
However, `v` can be caught by other variables, and the return value generated
|
||||
by `foo()` is used as a temporary value. Once copied by `v`,
|
||||
it will be destroyed immediately, and cannot be obtained or modified.
|
||||
The xvalue defines an behavior in which temporary values can be identified
|
||||
while being able to be moved.
|
||||
In such code, as far as the traditional understanding is concerned,
|
||||
the return value `temp` of the function `foo` is internally created
|
||||
and then assigned to `v`, whereas when `v` gets this object, the entire `temp` is copied.
|
||||
And then destroy `temp`, if this `temp` is very large, this will cause a lot of extra
|
||||
overhead (this is the problem that traditional C++ has been criticized for).
|
||||
In the last line, `v` is the lvalue, and the value returned by `foo()` is
|
||||
the rvalue (which is also a pure rvalue).
|
||||
|
||||
After C++11, the compiler did some work for us, where the lvalue `temp`
|
||||
is subjected to this implicit rvalue conversion,
|
||||
equivalent to `static_cast<std::vector<int> &&>(temp)`,
|
||||
where `v` here moves the value returned by `foo` locally.
|
||||
However, `v` can be caught by other variables, and the return value generated by `foo()`
|
||||
is used as a temporary value. Once copied by `v`, it will be destroyed immediately, and
|
||||
cannot be obtained or modified. The xvalue defines behavior in which temporary values can be
|
||||
identified while being able to be moved.
|
||||
|
||||
After C++11, the compiler did some work for us, where the lvalue `temp`
|
||||
is subjected to this implicit rvalue conversion,
|
||||
equivalent to `static_cast<std::vector<int> &&>(temp)`,
|
||||
where `v` here moves the value returned by `foo` locally.
|
||||
This is the move semantics we will mention later.
|
||||
|
||||
### rvalue reference and lvalue reference
|
||||
|
||||
To get a xvalue, you need to use the declaration of the rvalue reference: `T &&`,
|
||||
To get a xvalue, you need to use the declaration of the rvalue reference: `T &&`,
|
||||
where `T` is the type.
|
||||
The statement of the rvalue reference extends the lifecycle of this temporary value,
|
||||
The statement of the rvalue reference extends the lifecycle of this temporary value,
|
||||
and as long as the variable is alive, the xvalue will continue to survive.
|
||||
|
||||
C++11 provides the `std::move` method to unconditionally convert
|
||||
C++11 provides the `std::move` method to unconditionally convert
|
||||
lvalue parameters to rvalues.
|
||||
With it we can easily get a rvalue temporary object, for example:
|
||||
|
||||
@@ -339,25 +338,25 @@ int main()
|
||||
// std::string&& r1 = s1; // illegal, rvalue can't ref to lvalue
|
||||
std::string&& rv1 = std::move(lv1); // legal, std::move can convert lvalue to rvalue
|
||||
std::cout << rv1 << std::endl; // string,
|
||||
|
||||
|
||||
const std::string& lv2 = lv1 + lv1; // legal, const lvalue reference can extend temp variable's lifecycle
|
||||
// lv2 += "Test"; // illegal, const ref can't be modified
|
||||
std::cout << lv2 << std::endl; // string,string
|
||||
|
||||
|
||||
std::string&& rv2 = lv1 + lv2; // legal, rvalue ref extend lifecycle
|
||||
rv2 += "string"; // legal, non-const reference can be modified
|
||||
std::cout << rv2 << std::endl; // string,string,string,string
|
||||
|
||||
|
||||
reference(rv2); // output: lvalue
|
||||
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
`rv2` refers to an rvalue, but since it is a reference,
|
||||
`rv2` refers to an rvalue, but since it is a reference,
|
||||
`rv2` is still an lvalue.
|
||||
|
||||
Note that there is a very interesting historical issue here,
|
||||
Note that there is a very interesting historical issue here,
|
||||
let's look at the following code:
|
||||
|
||||
```cpp
|
||||
@@ -371,7 +370,7 @@ int main() {
|
||||
}
|
||||
```
|
||||
|
||||
The first question, why not allow non-linear references to bind to non-lvalues?
|
||||
The first question, why not allow non-linear references to bind to non-lvalues?
|
||||
This is because there is a logic error in this approach:
|
||||
|
||||
```cpp
|
||||
@@ -384,28 +383,28 @@ void foo() {
|
||||
}
|
||||
```
|
||||
|
||||
Since `int&` can't reference a parameter of type `double`,
|
||||
Since `int&` can't reference a parameter of type `double`,
|
||||
you must generate a temporary value to hold the value of `s`.
|
||||
Thus, when `increase()` modifies this temporary value,
|
||||
Thus, when `increase()` modifies this temporary value,
|
||||
`s` itself is not modified after the call is completed.
|
||||
|
||||
The second question, why do constant references allow binding to non-lvalues?
|
||||
The second question, why do constant references allow binding to non-lvalues?
|
||||
The reason is simple because Fortran needs it.
|
||||
|
||||
### Move semantics
|
||||
|
||||
Traditional C++ has designed the concept of copy/copy for class objects
|
||||
through copy constructors and assignment operators,
|
||||
but in order to implement the movement of resources,
|
||||
The caller must use the method of copying and then destructing first,
|
||||
otherwise you need to implement the interface of the mobile object yourself.
|
||||
Imagine moving your home directly to your new home instead of
|
||||
Traditional C++ has designed the concept of copy/copy for class objects
|
||||
through copy constructors and assignment operators,
|
||||
but to implement the movement of resources,
|
||||
The caller must use the method of copying and then destructing first,
|
||||
otherwise, you need to implement the interface of the mobile object yourself.
|
||||
Imagine moving your home directly to your new home instead of
|
||||
copying everything (rebuy) to your new home.
|
||||
Throwing away (destroying) all the original things is a very anti-human thing.
|
||||
|
||||
Traditional C++ does not distinguish between the concepts of "mobile" and "copy",
|
||||
Traditional C++ does not distinguish between the concepts of "mobile" and "copy",
|
||||
resulting in a large amount of data copying, wasting time and space.
|
||||
The appearance of rvalue references solves the confusion of these two concepts,
|
||||
The appearance of rvalue references solves the confusion of these two concepts,
|
||||
for example:
|
||||
|
||||
```cpp
|
||||
@@ -413,19 +412,19 @@ for example:
|
||||
class A {
|
||||
public:
|
||||
int *pointer;
|
||||
A():pointer(new int(1)) {
|
||||
std::cout << "construct" << pointer << std::endl;
|
||||
A():pointer(new int(1)) {
|
||||
std::cout << "construct" << pointer << std::endl;
|
||||
}
|
||||
A(A& a):pointer(new int(*a.pointer)) {
|
||||
std::cout << "copy" << pointer << std::endl;
|
||||
A(A& a):pointer(new int(*a.pointer)) {
|
||||
std::cout << "copy" << pointer << std::endl;
|
||||
} // meaningless object copy
|
||||
A(A&& a):pointer(a.pointer) {
|
||||
A(A&& a):pointer(a.pointer) {
|
||||
a.pointer = nullptr;
|
||||
std::cout << "move" << pointer << std::endl;
|
||||
std::cout << "move" << pointer << std::endl;
|
||||
}
|
||||
~A(){
|
||||
std::cout << "destruct" << pointer << std::endl;
|
||||
delete pointer;
|
||||
~A(){
|
||||
std::cout << "destruct" << pointer << std::endl;
|
||||
delete pointer;
|
||||
}
|
||||
};
|
||||
// avoid compiler optimization
|
||||
@@ -448,7 +447,7 @@ In the code above:
|
||||
1. First construct two `A` objects inside `return_rvalue`, and get the output of the two constructors;
|
||||
2. After the function returns, it will generate a xvalue, which is referenced by the moving structure of `A` (`A(A&&)`), thus extending the life cycle, and taking the pointer in the rvalue and saving it to `obj`. In the middle, the pointer to the xvalue is set to `nullptr`, which prevents the memory area from being destroyed.
|
||||
|
||||
This avoids meaningless copy constructs and enhances performance.
|
||||
This avoids meaningless copy constructs and enhances performance.
|
||||
Let's take a look at an example involving a standard library:
|
||||
|
||||
```cpp
|
||||
@@ -458,28 +457,28 @@ Let's take a look at an example involving a standard library:
|
||||
#include <string> // std::string
|
||||
|
||||
int main() {
|
||||
|
||||
|
||||
std::string str = "Hello world.";
|
||||
std::vector<std::string> v;
|
||||
|
||||
|
||||
// use push_back(const T&), copy
|
||||
v.push_back(str);
|
||||
// "str: Hello world."
|
||||
std::cout << "str: " << str << std::endl;
|
||||
|
||||
|
||||
// use push_back(const T&&), no copy
|
||||
// the string will be moved to vector, and therefore std::move can reduce copy cost
|
||||
v.push_back(std::move(str));
|
||||
// str is empty now
|
||||
std::cout << "str: " << str << std::endl;
|
||||
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
### Perfect forwarding
|
||||
|
||||
As we mentioned earlier, the rvalue reference of a declaration is actually an lvalue.
|
||||
As we mentioned earlier, the rvalue reference of a declaration is actually an lvalue.
|
||||
This creates problems for us to parameterize (pass):
|
||||
|
||||
```cpp
|
||||
@@ -513,21 +512,21 @@ Therefore `reference(v)` will call `reference(int&)` and output lvalue.
|
||||
For `pass(l)`, `l` is an lvalue, why is it successfully passed to `pass(T&&)`?
|
||||
|
||||
This is based on the **reference collapsing rule**: In traditional C++, we are not able to continue to reference a reference type.
|
||||
However,
|
||||
C++ has relaxed this practice with the advent of rvalue references,
|
||||
resulting in a reference collapse rule that allows us to reference references,
|
||||
However,
|
||||
C++ has relaxed this practice with the advent of rvalue references,
|
||||
resulting in a reference collapse rule that allows us to reference references,
|
||||
both lvalue and rvalue. But follow the rules below:
|
||||
|
||||
| Function parameter type | Argument parameter type | Post-derivation function parameter type |
|
||||
| :--------: | :--------: | :-------------: |
|
||||
| T& | lvalue ref | T& |
|
||||
| T& | rvalue ref | T& |
|
||||
| T&& | lvalue ref | T& |
|
||||
| T&& | rvalue ref | T&& |
|
||||
| :---------------------: | :---------------------: | :-------------------------------------: |
|
||||
| T& | lvalue ref | T& |
|
||||
| T& | rvalue ref | T& |
|
||||
| T&& | lvalue ref | T& |
|
||||
| T&& | rvalue ref | T&& |
|
||||
|
||||
Therefore, the use of `T&&` in a template function may not be able to make an rvalue reference, and when a lvalue is passed, a reference to this function will be derived as an lvalue.
|
||||
More precisely, ** no matter what type of reference the template parameter is, the template parameter can be derived as a right reference type** if and only if the argument type is a right reference.
|
||||
This makes `v` a successful delivery of lvalues.
|
||||
This makes `v` successful delivery of lvalues.
|
||||
|
||||
Perfect forwarding is based on the above rules. The so-called perfect forwarding is to let us pass the parameters,
|
||||
Keep the original parameter type (lvalue reference keeps lvalue reference, rvalue reference keeps rvalue reference).
|
||||
@@ -556,11 +555,11 @@ void pass(T&& v) {
|
||||
int main() {
|
||||
std::cout << "rvalue pass:" << std::endl;
|
||||
pass(1);
|
||||
|
||||
|
||||
std::cout << "lvalue pass:" << std::endl;
|
||||
int l = 1;
|
||||
pass(l);
|
||||
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
@@ -583,11 +582,11 @@ static_cast<T&&> param passing: lvalue reference
|
||||
Regardless of whether the pass parameter is an lvalue or an rvalue, the normal pass argument will forward the argument as an lvalue.
|
||||
So `std::move` will always accept an lvalue, which forwards the call to `reference(int&&)` to output the rvalue reference.
|
||||
|
||||
Only `std::forward` does not cause any extra copies, and ** perfectly forwards ** (passes) the arguments of the function to other functions that are called internally.
|
||||
Only `std::forward` does not cause any extra copies and ** perfectly forwards ** (passes) the arguments of the function to other functions that are called internally.
|
||||
|
||||
`std::forward` is the same as `std::move`, and nothing is done. `std::move` simply converts the lvalue to the rvalue.
|
||||
`std::forward` is just a simple conversion of the parameters. From the point of view of the phenomenon,
|
||||
`std::forward<T>(v)` is exactly the same as `static_cast<T&&>(v)`.
|
||||
`std::forward<T>(v)` is the same as `static_cast<T&&>(v)`.
|
||||
|
||||
Readers may be curious as to why a statement can return values for two types of returns.
|
||||
Let's take a quick look at the concrete implementation of `std::forward`. `std::forward` contains two overloads:
|
||||
@@ -614,7 +613,7 @@ When `std::forward` accepts an lvalue, `_Tp` is deduced to the lvalue, so the re
|
||||
`_Tp` is derived as an rvalue reference, and based on the collapse rule, the return value becomes the rvalue of `&& + &&`.
|
||||
It can be seen that the principle of `std::forward` is to make clever use of the differences in template type derivation.
|
||||
|
||||
At this point we can answer the question: Why is `auto&&` the safest way to use looping statements?
|
||||
At this point, we can answer the question: Why is `auto&&` the safest way to use looping statements?
|
||||
Because when `auto` is pushed to a different lvalue and rvalue reference, the collapsed combination with `&&` is perfectly forwarded.
|
||||
|
||||
## Conclusion
|
||||
@@ -622,6 +621,7 @@ Because when `auto` is pushed to a different lvalue and rvalue reference, the co
|
||||
This chapter introduces the most important runtime enhancements in modern C++, and I believe that all the features mentioned in this section are worth knowing:
|
||||
|
||||
Lambda expression
|
||||
|
||||
1. Function object container std::function
|
||||
2. rvalue reference
|
||||
|
||||
|
||||
@@ -12,13 +12,13 @@ order: 4
|
||||
|
||||
### `std::array`
|
||||
|
||||
When you see this container, you will definitely have this problem:
|
||||
When you see this container, you will have this problem:
|
||||
|
||||
1. Why introduce `std::array` instead of `std::vector` directly?
|
||||
2. Already have a traditional array, why use `std::array`?
|
||||
|
||||
First answer the first question. Unlike `std::vector`, the size of the `std::array` object is fixed. If the container size is fixed, then the `std::array` container can be used first.
|
||||
In addition, since `std::vector` is automatically expanded, when a large amount of data is stored, and the container is deleted,
|
||||
First, answer the first question. Unlike `std::vector`, the size of the `std::array` object is fixed. If the container size is fixed, then the `std::array` container can be used first.
|
||||
Also, since `std::vector` is automatically expanded, when a large amount of data is stored, and the container is deleted,
|
||||
The container does not automatically return the corresponding memory of the deleted element. In this case, you need to manually run `shrink_to_fit()` to release this part of the memory.
|
||||
|
||||
```cpp
|
||||
@@ -26,9 +26,9 @@ std::vector<int> v;
|
||||
std::cout << "size:" << v.size() << std::endl; // output 0
|
||||
std::cout << "capacity:" << v.capacity() << std::endl; // output 0
|
||||
|
||||
// As you can see, the storage of std::vector is automatically managed and
|
||||
// As you can see, the storage of std::vector is automatically managed and
|
||||
// automatically expanded as needed.
|
||||
// But if there is not enough space, you need to redistribute more memory,
|
||||
// But if there is not enough space, you need to redistribute more memory,
|
||||
// and reallocating memory is usually a performance-intensive operation.
|
||||
v.push_back(1);
|
||||
v.push_back(2);
|
||||
@@ -42,9 +42,9 @@ v.push_back(5);
|
||||
std::cout << "size:" << v.size() << std::endl; // output 5
|
||||
std::cout << "capacity:" << v.capacity() << std::endl; // output 8
|
||||
|
||||
// As can be seen below, although the container empties the element,
|
||||
// As can be seen below, although the container empties the element,
|
||||
// the memory of the emptied element is not returned.
|
||||
v.clear();
|
||||
v.clear();
|
||||
std::cout << "size:" << v.size() << std::endl; // output 0
|
||||
std::cout << "capacity:" << v.capacity() << std::endl; // output 8
|
||||
|
||||
@@ -103,7 +103,7 @@ std::sort(arr.begin(), arr.end());
|
||||
|
||||
### `std::forward_list`
|
||||
|
||||
`std::forward_list` is a list container, and the usage is basically similar to `std::list`, so we don't spend a lot of time introducing it.
|
||||
`std::forward_list` is a list container, and the usage is similar to `std::list`, so we don't spend a lot of time introducing it.
|
||||
|
||||
Need to know is that, unlike the implementation of the doubly linked list of `std::list`, `std::forward_list` is implemented using a singly linked list.
|
||||
Provides element insertion of `O(1)` complexity, does not support fast random access (this is also a feature of linked lists),
|
||||
@@ -115,7 +115,7 @@ We are already familiar with the ordered container `std::map`/`std::set` in trad
|
||||
The average complexity of inserts and searches is `O(log(size))`. When inserting an element, the element size is compared according to the `<` operator and the element is determined to be the same.
|
||||
And select the appropriate location to insert into the container. When traversing the elements in this container, the output will be traversed one by one in the order of the `<` operator.
|
||||
|
||||
The elements in the unordered container are not sorted, and the internals are implemented by the Hash table. The average complexity of inserting and searching for elements is `O(constant)`,
|
||||
The elements in the unordered container are not sorted, and the internals is implemented by the Hash table. The average complexity of inserting and searching for elements is `O(constant)`,
|
||||
Significant performance gains can be achieved without concern for the order of the elements inside the container.
|
||||
|
||||
C++11 introduces two sets of unordered containers: `std::unordered_map`/`std::unordered_multimap` and
|
||||
@@ -142,12 +142,12 @@ int main() {
|
||||
{3, "3"},
|
||||
{2, "2"}
|
||||
};
|
||||
|
||||
|
||||
// iterates in the same way
|
||||
std::cout << "std::unordered_map" << std::endl;
|
||||
for( const auto & n : u)
|
||||
std::cout << "Key:[" << n.first << "] Value:[" << n.second << "]\n";
|
||||
|
||||
|
||||
std::cout << std::endl;
|
||||
std::cout << "std::map" << std::endl;
|
||||
for( const auto & n : v)
|
||||
@@ -256,8 +256,8 @@ constexpr std::variant<T...> tuple_index(const std::tuple<T...>& tpl, size_t i)
|
||||
return _tuple_index<0>(tpl, i);
|
||||
}
|
||||
template <typename T0, typename ... Ts>
|
||||
std::ostream & operator<< (std::ostream & s, std::variant<T0, Ts...> const & v) {
|
||||
std::visit([&](auto && x){ s << x;}, v);
|
||||
std::ostream & operator<< (std::ostream & s, std::variant<T0, Ts...> const & v) {
|
||||
std::visit([&](auto && x){ s << x;}, v);
|
||||
return s;
|
||||
}
|
||||
```
|
||||
@@ -278,7 +278,7 @@ auto new_tuple = std::tuple_cat(get_student(1), std::move(t));
|
||||
```
|
||||
|
||||
You can immediately see how quickly you can traverse a tuple? But we just introduced how to index a `tuple` by a very number at runtime, then the traversal becomes simpler.
|
||||
First we need to know the length of a tuple, which can:
|
||||
First, we need to know the length of a tuple, which can:
|
||||
|
||||
```cpp
|
||||
template <typename T>
|
||||
@@ -297,7 +297,7 @@ for(int i = 0; i != tuple_len(new_tuple); ++i)
|
||||
|
||||
## Conclusion
|
||||
|
||||
This chapter briefly introduces the new containers in modern C++. Their usage is similar to that of the existing containers in C++. It is relatively simple, and you can choose the containers you need to use according to the actual scene, so as to get better performance.
|
||||
This chapter briefly introduces the new containers in modern C++. Their usage is similar to that of the existing containers in C++. It is relatively simple, and you can choose the containers you need to use according to the actual scene, to get better performance.
|
||||
|
||||
Although `std::tuple` is effective, the standard library provides limited functionality and there is no way to meet the requirements of runtime indexing and iteration. Fortunately, we have other methods that we can implement on our own.
|
||||
|
||||
@@ -305,4 +305,4 @@ Although `std::tuple` is effective, the standard library provides limited functi
|
||||
|
||||
## Licenses
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
|
||||
@@ -18,11 +18,11 @@ In traditional C++, "remembering" to manually release resources is not always a
|
||||
So the usual practice is that for an object, we apply for space when constructor, and free space when the destructor (called when leaving the scope).
|
||||
That is, we often say that the RAII resource acquisition is the initialization technology.
|
||||
|
||||
There are exceptions to everything, we always have the need to allocate objects on free storage. In traditional C++ we have to use `new` and `delete` to "remember" to release resources. C++11 introduces the concept of smart pointers, using the idea of reference counting, so that programmers no longer need to care about manually releasing memory.
|
||||
There are exceptions to everything, we always need to allocate objects on free storage. In traditional C++ we have to use `new` and `delete` to "remember" to release resources. C++11 introduces the concept of smart pointers, using the idea of reference counting so that programmers no longer need to care about manually releasing memory.
|
||||
These smart pointers include `std::shared_ptr`/`std::unique_ptr`/`std::weak_ptr`, which need to include the header file `<memory>`.
|
||||
|
||||
> Note: The reference count is not garbage collection. The reference count can recover the objects that are no longer used as soon as possible, and will not cause long waits during the recycling process.
|
||||
> More clearly and clearly indicate the life cycle of resources.
|
||||
> More clearly and indicate the life cycle of resources.
|
||||
|
||||
## 5.2 `std::shared_ptr`
|
||||
|
||||
@@ -86,7 +86,7 @@ std::unique_ptr<int> pointer2 = pointer; // illegal
|
||||
```
|
||||
|
||||
> `make_unique` is not complicated. C++11 does not provide `std::make_unique`, which can be implemented by itself:
|
||||
>
|
||||
>
|
||||
> ```cpp
|
||||
> template<typename T, typename ...Args>
|
||||
> std::unique_ptr<T> make_unique( Args&& ...args ) {
|
||||
@@ -114,30 +114,30 @@ void f(const Foo &) {
|
||||
|
||||
int main() {
|
||||
std::unique_ptr<Foo> p1(std::make_unique<Foo>());
|
||||
|
||||
|
||||
// p1 is not empty, prints
|
||||
if (p1) p1->foo();
|
||||
{
|
||||
std::unique_ptr<Foo> p2(std::move(p1));
|
||||
|
||||
|
||||
// p2 is not empty, prints
|
||||
f(*p2);
|
||||
|
||||
|
||||
// p2 is not empty, prints
|
||||
if(p2) p2->foo();
|
||||
|
||||
|
||||
// p1 is empty, no prints
|
||||
if(p1) p1->foo();
|
||||
|
||||
|
||||
p1 = std::move(p2);
|
||||
|
||||
|
||||
// p2 is empty, no prints
|
||||
if(p2) p2->foo();
|
||||
std::cout << "p2 was destroyed" << std::endl;
|
||||
}
|
||||
// p1 is not empty, prints
|
||||
if (p1) p1->foo();
|
||||
|
||||
|
||||
// Foo instance will be destroyed when leaving the scope
|
||||
}
|
||||
```
|
||||
@@ -172,12 +172,12 @@ int main() {
|
||||
std::shared_ptr<B> b = std::make_shared<B>();
|
||||
a->pointer = b;
|
||||
b->pointer = a;
|
||||
|
||||
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
The result is that A and B will not be destroyed. This is because the pointer inside a, b also references `a, b`, which makes the reference count of `a, b` become 2, leaving the scope. When the `a, b` smart pointer is destructed, it can only cause the reference count of this area to be decremented by one. This causes the memory area reference count pointed to by the `a, b` object to be non-zero, but the external has no way to find this area, it also caused a memory leak, as shown in Figure 5.1:
|
||||
The result is that A and B will not be destroyed. This is because the pointer inside a, b also references `a, b`, which makes the reference count of `a, b` becomes 2, leaving the scope. When the `a, b` smart pointer is destructed, it can only cause the reference count of this area to be decremented by one. This causes the memory area reference count pointed to by the `a, b` object to be non-zero, but the external has no way to find this area, it also caused a memory leak, as shown in Figure 5.1:
|
||||
|
||||
|
||||
|
||||
@@ -187,7 +187,7 @@ The solution to this problem is to use the weak reference pointer `std::weak_ptr
|
||||
|
||||
In the above figure, only B is left in the last step, and B does not have any smart pointers to reference it, so this memory resource will also be released.
|
||||
|
||||
`std::weak_ptr` has no `*` operator and `->` operator, so it can't operate on resources. Its only function is to check if `std::shared_ptr` exists, its `expired()` method can return `false` when the resource is not released, otherwise it returns `true`.
|
||||
`std::weak_ptr` has no `*` operator and `->` operator, so it can't operate on resources. Its only function is to check if `std::shared_ptr` exists, its `expired()` method can return `false` when the resource is not released, otherwise, it returns `true`.
|
||||
|
||||
## Conclusion
|
||||
|
||||
|
||||
@@ -10,64 +10,62 @@ order: 6
|
||||
|
||||
## 6.1 Introduction
|
||||
|
||||
Regular expressions are not part of the C++ language and therefore we only briefly
|
||||
Regular expressions are not part of the C++ language and therefore we only briefly
|
||||
introduced it here.
|
||||
|
||||
Regular expressions describe a pattern of string matching.
|
||||
The general use of regular expressions is mainly to achieve
|
||||
Regular expressions describe a pattern of string matching.
|
||||
The general use of regular expressions is mainly to achieve
|
||||
the following three requirements:
|
||||
|
||||
1. Check if a string contains some form of substring;
|
||||
2. Replace the matching substrings;
|
||||
3. Take the eligible substring from a string.
|
||||
|
||||
Regular expressions are text patterns consisting of ordinary characters (such as a to z)
|
||||
and special characters. A pattern describes one or more strings to match when searching for text.
|
||||
Regular expressions are text patterns consisting of ordinary characters (such as a to z)
|
||||
and special characters. A pattern describes one or more strings to match when searching for text.
|
||||
Regular expressions act as a template to match a character pattern to the string being searched.
|
||||
|
||||
### Ordinary characters
|
||||
|
||||
Normal characters include all printable and unprintable characters that
|
||||
are not explicitly specified as metacharacters. This includes all uppercase
|
||||
Normal characters include all printable and unprintable characters that are not explicitly specified as metacharacters. This includes all uppercase
|
||||
and lowercase letters, all numbers, all punctuation, and some other symbols.
|
||||
|
||||
### Special characters
|
||||
|
||||
A special character is a character with special meaning in a regular expression,
|
||||
and is also the core matching syntax of a regular expression. See the table below:
|
||||
A special character is a character with special meaning in a regular expression and is also the core matching syntax of a regular expression. See the table below:
|
||||
|
||||
|Special characters|Description|
|
||||
|:---:|:------------------------------------------------------|
|
||||
|`$`| Matches the end position of the input string. |
|
||||
|`(`,`)`| Marks the start and end of a subexpression. Subexpressions can be obtained for later use. |
|
||||
|`*`| Matches the previous subexpression zero or more times. |
|
||||
|`+`| Matches the previous subexpression one or more times. |
|
||||
|`.`| Matches any single character except the newline character `\n`. |
|
||||
|`[`| Marks the beginning of a bracket expression. |
|
||||
|`?`| Matches the previous subexpression zero or one time, or indicates a non-greedy qualifier. |
|
||||
| `\`| Marks the next character as either a special character, or a literal character, or a backward reference, or an octal escape character. For example, `n` Matches the character `n`. `\n` matches newline characters. The sequence `\\` Matches the `'\'` character, while `\(` matches the `'('` character.|
|
||||
|`^`| Matches the beginning of the input string, unless it is used in a square bracket expression, at which point it indicates that the set of characters is not accepted. |
|
||||
|`{`| Marks the beginning of a qualifier expression. |
|
||||
|`\|`| Indicates a choice between the two. |
|
||||
| Special characters | Description |
|
||||
| :----------------: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `$` | Matches the end position of the input string. |
|
||||
| `(`,`)` | Marks the start and end of a subexpression. Subexpressions can be obtained for later use. |
|
||||
| `*` | Matches the previous subexpression zero or more times. |
|
||||
| `+` | Matches the previous subexpression one or more times. |
|
||||
| `.` | Matches any single character except the newline character `\n`. |
|
||||
| `[` | Marks the beginning of a bracket expression. |
|
||||
| `?` | Matches the previous subexpression zero or one time, or indicates a non-greedy qualifier. |
|
||||
| `\` | Marks the next character as either a special character, or a literal character, or a backward reference, or an octal escape character. For example, `n` Matches the character `n`. `\n` matches newline characters. The sequence `\\` Matches the `'\'` character, while `\(` matches the `'('` character. |
|
||||
| `^` | Matches the beginning of the input string, unless it is used in a square bracket expression, at which point it indicates that the set of characters is not accepted. |
|
||||
| `{` | Marks the beginning of a qualifier expression. |
|
||||
| `\|` | Indicates a choice between the two. |
|
||||
|
||||
### Quantifiers
|
||||
|
||||
The qualifier is used to specify how many times a given component of a regular expression must appear to satisfy the match. See the table below:
|
||||
|
||||
|Character|Description|
|
||||
|:---:|:------------------------------------------------------|
|
||||
|`*`| matches the previous subexpression zero or more times. For example, `foo*` matches `fo` and `foooo`. `*` is equivalent to `{0,}`. |
|
||||
|`+`| matches the previous subexpression one or more times. For example, `foo+` matches `foo` and `foooo` but does not match `fo`. `+` is equivalent to `{1,}`. |
|
||||
|`?`| matches the previous subexpression zero or one time. For example, `Your(s)?` can match `Your` in `Your` or `Yours`. `?` is equivalent to `{0,1}`. |
|
||||
|`{n}`| `n` is a non-negative integer. Matches the determined `n` times. For example, `o{2}` cannot match `o` in `for`, but can match two `o` in `foo`. |
|
||||
|`{n,}`| `n` is a non-negative integer. Match at least `n` times. For example, `o{2,}` cannot match `o` in `for`, but matches all `o` in `foooooo`. `o{1,}` is equivalent to `o+`. `o{0,}` is equivalent to `o*`. |
|
||||
|`{n,m}`| `m` and `n` are non-negative integers, where `n` is less than or equal to `m`. Matches at least `n` times and matches up to `m` times. For example, `o{1,3}` will match the first three `o` in `foooooo`. `o{0,1}` is equivalent to `o?`. Note that there can be no spaces between the comma and the two numbers. |
|
||||
| Character | Description |
|
||||
| :-------: | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `*` | matches the previous subexpression zero or more times. For example, `foo*` matches `fo` and `foooo`. `*` is equivalent to `{0,}`. |
|
||||
| `+` | matches the previous subexpression one or more times. For example, `foo+` matches `foo` and `foooo` but does not match `fo`. `+` is equivalent to `{1,}`. |
|
||||
| `?` | matches the previous subexpression zero or one time. For example, `Your(s)?` can match `Your` in `Your` or `Yours`. `?` is equivalent to `{0,1}`. |
|
||||
| `{n}` | `n` is a non-negative integer. Matches the determined `n` times. For example, `o{2}` cannot match `o` in `for`, but can match two `o` in `foo`. |
|
||||
| `{n,}` | `n` is a non-negative integer. Match at least `n` times. For example, `o{2,}` cannot match `o` in `for`, but matches all `o` in `foooooo`. `o{1,}` is equivalent to `o+`. `o{0,}` is equivalent to `o*`. |
|
||||
| `{n,m}` | `m` and `n` are non-negative integers, where `n` is less than or equal to `m`. Matches at least `n` times and matches up to `m` times. For example, `o{1,3}` will match the first three `o` in `foooooo`. `o{0,1}` is equivalent to `o?`. Note that there can be no spaces between the comma and the two numbers. |
|
||||
|
||||
With these two tables, we can usually read almost all regular expressions.
|
||||
|
||||
## 6.2 `std::regex` and Its Related
|
||||
|
||||
The most common way to match string content is to use regular expressions. Unfortunately, in traditional C++, regular expressions have not been supported by the language level, and are not included in the standard library. C++ is a high-performance language. In the development of background services, the use of regular expressions is also used when judging URL resource links. The most mature and common practice in industry.
|
||||
The most common way to match string content is to use regular expressions. Unfortunately, in traditional C++, regular expressions have not been supported by the language level, and are not included in the standard library. C++ is a high-performance language. In the development of background services, the use of regular expressions is also used when judging URL resource links. The most mature and common practice in the industry.
|
||||
|
||||
The general solution is to use the regular expression library of `boost`. C++11 officially incorporates the processing of regular expressions into the standard library, providing standard support from the language level and no longer relying on third parties.
|
||||
|
||||
@@ -77,7 +75,7 @@ We use a simple example to briefly introduce the use of this library. Consider t
|
||||
|
||||
- `[az]+\.txt`: In this regular expression, `[az]` means matching a lowercase letter, `+` can match the previous expression multiple times, so `[az]+` can Matches a string of lowercase letters. In the regular expression, a `.` means to match any character, and `\.` means to match the character `.`, and the last `txt` means to match `txt` exactly three letters. So the content of this regular expression to match is a text file consisting of pure lowercase letters.
|
||||
|
||||
`std::regex_match` is used to match strings and regular expressions, and there are many different overloaded forms. The simplest form is to pass `std::string` and a `std::regex` to match. When the match is successful, it will return `true`, otherwise it will return `false`. For example:
|
||||
`std::regex_match` is used to match strings and regular expressions, and there are many different overloaded forms. The simplest form is to pass `std::string` and a `std::regex` to match. When the match is successful, it will return `true`, otherwise, it will return `false`. For example:
|
||||
|
||||
```cpp
|
||||
#include <iostream>
|
||||
@@ -131,14 +129,14 @@ bar.txt sub-match[1]: bar
|
||||
|
||||
## Conclusion
|
||||
|
||||
This section briefly introduces the regular expression itself,
|
||||
and then introduces the use of the regular expression library
|
||||
through a practical example based on the main requirements of
|
||||
This section briefly introduces the regular expression itself,
|
||||
and then introduces the use of the regular expression library
|
||||
through a practical example based on the main requirements of
|
||||
using regular expressions.
|
||||
|
||||
## Exercise
|
||||
|
||||
In web server development, we usually want to serve some routes that satisfy a certain condition.
|
||||
In web server development, we usually want to serve some routes that satisfy a certain condition.
|
||||
Regular expressions are one of the tools to accomplish this.
|
||||
Given the following request structure:
|
||||
|
||||
@@ -230,4 +228,4 @@ An suggested solution can be found [here](../../exercises/6).
|
||||
|
||||
## Licenses
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
|
||||
@@ -28,7 +28,7 @@ int main() {
|
||||
|
||||
## 7.2 Mutex and Critical Section
|
||||
|
||||
We have already learned the basics of concurrency technology in the operating system, or in the database, and `mutex` is one of the cores.
|
||||
We have already learned the basics of concurrency technology in the operating system, or the database, and `mutex` is one of the cores.
|
||||
C++11 introduces a class related to `mutex`, with all related functions in the `<mutex>` header file.
|
||||
|
||||
`std::mutex` is the most basic `mutex` class in C++11, and you can create a mutex by instantiating `std::mutex`.
|
||||
@@ -114,10 +114,10 @@ int main() {
|
||||
## 7.3 Future
|
||||
|
||||
The Future is represented by `std::future`, which provides a way to access the results of asynchronous operations. This sentence is very difficult to understand.
|
||||
In order to understand this feature, we need to understand the multi-threaded behavior before C++11.
|
||||
To understand this feature, we need to understand the multi-threaded behavior before C++11.
|
||||
|
||||
Imagine if our main thread A wants to open a new thread B to perform some of our expected tasks and return me a result.
|
||||
At this time, thread A may be busy with other things, and have no time to take into account the results of B.
|
||||
At this time, thread A may be busy with other things and have no time to take into account the results of B.
|
||||
So we naturally hope to get the result of thread B at a certain time.
|
||||
|
||||
Before the introduction of `std::future` in C++11, the usual practice is:
|
||||
@@ -217,15 +217,15 @@ int main() {
|
||||
}
|
||||
```
|
||||
|
||||
It is worth mentioning that although we can use `notify_one()` in the producer, it is not really recommended to use it here.
|
||||
Because in the case of multiple consumers, our consumer implementation simply gives up the lock holding, which makes it possible for other consumers to compete for this lock, so as to better utilize the concurrency between multiple consumers. Having said that, but in fact because of the exclusivity of `std::mutex`,
|
||||
We simply can't expect multiple consumers to be able to actually produce content in a parallel consumer queue, and we still need a more granular approach.
|
||||
It is worth mentioning that although we can use `notify_one()` in the producer, it is not recommended to use it here.
|
||||
Because in the case of multiple consumers, our consumer implementation simply gives up the lock holding, which makes it possible for other consumers to compete for this lock, to better utilize the concurrency between multiple consumers. Having said that, but in fact because of the exclusivity of `std::mutex`,
|
||||
We simply can't expect multiple consumers to be able to produce content in a parallel consumer queue, and we still need a more granular approach.
|
||||
|
||||
## 7.5 Atomic Operation and Memory Model
|
||||
|
||||
Careful readers may be tempted by the fact that the example of the producer consumer model in the previous section may have compiler optimizations that cause program errors.
|
||||
Careful readers may be tempted by the fact that the example of the producer-consumer model in the previous section may have compiler optimizations that cause program errors.
|
||||
For example, the boolean `notified` is not modified by `volatile`, and the compiler may have optimizations for this variable, such as the value of a register.
|
||||
As a result, the consumer thread can never observe the change of this value. This is a good question. To explain this problem, we need to further discuss the concept of memory model introduced from C++11. Let's first look at a question. What is the output of the following code?
|
||||
As a result, the consumer thread can never observe the change of this value. This is a good question. To explain this problem, we need to further discuss the concept of the memory model introduced from C++11. Let's first look at a question. What is the output of the following code?
|
||||
|
||||
```cpp
|
||||
#include <thread>
|
||||
@@ -254,19 +254,19 @@ int main() {
|
||||
```
|
||||
|
||||
Intuitively, `a = 5;` seems in `t2` seems to always execute before `flag = 1;`, and `while (flag != 1)` in `t1` seems to guarantee `std ::cout << "b = " << b << std::endl;` will not be executed before the mark is changed. Logically, it seems that the value of `b` should be equal to 5.
|
||||
But the actual situation is much more complicated than this, or the code itself is undefined behavior, because for `a` and `flag`, they are read and written in two parallel threads.
|
||||
There has been competition. In addition, even if we ignore competing reading and writing, it is still possible to receive out-of-order execution of the CPU, and the impact of the compiler on the rearrangement of instructions.
|
||||
But the actual situation is much more complicated than this, or the code itself is undefined behavior because, for `a` and `flag`, they are read and written in two parallel threads.
|
||||
There has been competition. Also, even if we ignore competing for reading and writing, it is still possible to receive out-of-order execution of the CPU and the impact of the compiler on the rearrangement of instructions.
|
||||
Cause `a = 5` to occur after `flag = 1`. Thus `b` may output 0.
|
||||
|
||||
### Atomic Operation
|
||||
|
||||
`std::mutex` can solve the problem of concurrent read and write, but the mutex is an operating system level function.
|
||||
`std::mutex` can solve the problem of concurrent read and write, but the mutex is an operating system-level function.
|
||||
This is because the implementation of a mutex usually contains two basic principles:
|
||||
|
||||
1. Provide automatic state transition between threads, that is, "lock" state
|
||||
2. Ensure that the memory of the manipulated variable is isolated from the critical section during the mutex operation
|
||||
|
||||
This is a very strong set of synchronization conditions, in other words, when it is finally compiled into a CPU instruction, it will behave as a lot of instructions (we will look at how to implement a simple mutex later).
|
||||
This is a very strong set of synchronization conditions, in other words when it is finally compiled into a CPU instruction, it will behave like a lot of instructions (we will look at how to implement a simple mutex later).
|
||||
This seems too harsh for a variable that requires only atomic operations (no intermediate state).
|
||||
|
||||
The research on synchronization conditions has a very long history, and we will not go into details here. Readers should understand that under the modern CPU architecture, atomic operations at the CPU instruction level are provided.
|
||||
@@ -335,207 +335,205 @@ Weakening the synchronization conditions between processes, usually we will cons
|
||||
|
||||
1. Linear consistency: Also known as strong consistency or atomic consistency. It requires that any read operation can read the most recent write of a certain data, and the order of operation of all threads is consistent with the order under the global clock.
|
||||
|
||||
```
|
||||
x.store(1) x.load()
|
||||
T1 ---------+----------------+------>
|
||||
```
|
||||
x.store(1) x.load()
|
||||
T1 ---------+----------------+------>
|
||||
|
||||
|
||||
T2 -------------------+------------->
|
||||
x.store(2)
|
||||
```
|
||||
T2 -------------------+------------->
|
||||
x.store(2)
|
||||
```
|
||||
|
||||
In this case, thread `T1`, `T2` is twice atomic to `x`, and `x.store(1)` is strictly before `x.store(2)`. `x.store(2)` strictly occurs before `x.load()`. It is worth mentioning that linear consistency requirements for global clocks are difficult to achieve, which is why people continue to study other consistent algorithms under this weaker consistency.
|
||||
In this case, thread `T1`, `T2` is twice atomic to `x`, and `x.store(1)` is strictly before `x.store(2)`. `x.store(2)` strictly occurs before `x.load()`. It is worth mentioning that linear consistency requirements for global clocks are difficult to achieve, which is why people continue to study other consistent algorithms under this weaker consistency.
|
||||
|
||||
2. Sequential consistency: It is also required that any read operation can read the last data written by the data, but it is not required to be consistent with the order of the global clock.
|
||||
|
||||
```
|
||||
x.store(1) x.store(3) x.load()
|
||||
T1 ---------+-----------+----------+----->
|
||||
```
|
||||
x.store(1) x.store(3) x.load()
|
||||
T1 ---------+-----------+----------+----->
|
||||
|
||||
|
||||
T2 ---------------+---------------------->
|
||||
x.store(2)
|
||||
T2 ---------------+---------------------->
|
||||
x.store(2)
|
||||
|
||||
or
|
||||
or
|
||||
|
||||
x.store(1) x.store(3) x.load()
|
||||
T1 ---------+-----------+----------+----->
|
||||
x.store(1) x.store(3) x.load()
|
||||
T1 ---------+-----------+----------+----->
|
||||
|
||||
|
||||
T2 ------+------------------------------->
|
||||
x.store(2)
|
||||
```
|
||||
T2 ------+------------------------------->
|
||||
x.store(2)
|
||||
```
|
||||
|
||||
Under the order consistency requirement, `x.load()` must read the last written data, so `x.store(2)` and `x.store(1)` do not have any guarantees, ie As long as `x.store(2)` of `T2` occurs before `x.store(3)`.
|
||||
Under the order consistency requirement, `x.load()` must read the last written data, so `x.store(2)` and `x.store(1)` do not have any guarantees, ie As long as `x.store(2)` of `T2` occurs before `x.store(3)`.
|
||||
|
||||
3. Causal consistency: its requirements are further reduced, only the sequence of causal operations is guaranteed, and the order of non-causal operations is not required.
|
||||
|
||||
```
|
||||
a = 1 b = 2
|
||||
T1 ----+-----------+---------------------------->
|
||||
```
|
||||
a = 1 b = 2
|
||||
T1 ----+-----------+---------------------------->
|
||||
|
||||
|
||||
T2 ------+--------------------+--------+-------->
|
||||
x.store(3) c = a + b y.load()
|
||||
T2 ------+--------------------+--------+-------->
|
||||
x.store(3) c = a + b y.load()
|
||||
|
||||
or
|
||||
or
|
||||
|
||||
a = 1 b = 2
|
||||
T1 ----+-----------+---------------------------->
|
||||
a = 1 b = 2
|
||||
T1 ----+-----------+---------------------------->
|
||||
|
||||
|
||||
T2 ------+--------------------+--------+-------->
|
||||
x.store(3) y.load() c = a + b
|
||||
T2 ------+--------------------+--------+-------->
|
||||
x.store(3) y.load() c = a + b
|
||||
|
||||
or
|
||||
or
|
||||
|
||||
b = 2 a = 1
|
||||
T1 ----+-----------+---------------------------->
|
||||
b = 2 a = 1
|
||||
T1 ----+-----------+---------------------------->
|
||||
|
||||
|
||||
T2 ------+--------------------+--------+-------->
|
||||
y.load() c = a + b x.store(3)
|
||||
```
|
||||
T2 ------+--------------------+--------+-------->
|
||||
y.load() c = a + b x.store(3)
|
||||
```
|
||||
|
||||
The three examples given above are all causal consistent, because in the whole process, only `c` has a dependency on `a` and `b`, and `x` and `y` are not related in this example. (But in actual situations we need more detailed information to determine that `x` is not related to `y`)
|
||||
The three examples given above are all causal consistent because, in the whole process, only `c` has a dependency on `a` and `b`, and `x` and `y` are not related in this example. (But in actual situations we need more detailed information to determine that `x` is not related to `y`)
|
||||
|
||||
4. Final Consistency: It is the weakest consistency requirement. It only guarantees that an operation will be observed at a certain point in the future, but does not require the observed time. So we can even strengthen this condition a bit, for example, to specify that the time observed for an operation is always bounded. Of course this is no longer within our discussion.
|
||||
4. Final Consistency: It is the weakest consistency requirement. It only guarantees that an operation will be observed at a certain point in the future, but does not require the observed time. So we can even strengthen this condition a bit, for example, to specify that the time observed for an operation is always bounded. Of course, this is no longer within our discussion.
|
||||
|
||||
```
|
||||
x.store(3) x.store(4)
|
||||
T1 ----+-----------+-------------------------------------------->
|
||||
```
|
||||
x.store(3) x.store(4)
|
||||
T1 ----+-----------+-------------------------------------------->
|
||||
|
||||
|
||||
T2 ---------+------------+--------------------+--------+-------->
|
||||
x.read() x.read() x.read() x.read()
|
||||
```
|
||||
T2 ---------+------------+--------------------+--------+-------->
|
||||
x.read() x.read() x.read() x.read()
|
||||
```
|
||||
|
||||
In the above case, if we assume that the initial value of x is 0, then the four times ``x.read()` in `T2` may be but not limited to the following:
|
||||
In the above case, if we assume that the initial value of x is 0, then the four times ``x.read()` in `T2` may be but not limited to the following:
|
||||
|
||||
```
|
||||
3 4 4 4 // The write operation of x was quickly observed
|
||||
0 3 3 4 // There is a delay in the observed time of the x write operation
|
||||
0 0 0 4 // The last read read the final value of x, but the previous changes were not observed.
|
||||
0 0 0 0 // The write operation of x is not observed in the current time period, but the situation that x is 4 can be observed at some point in the future.
|
||||
```
|
||||
```
|
||||
3 4 4 4 // The write operation of x was quickly observed
|
||||
0 3 3 4 // There is a delay in the observed time of the x write operation
|
||||
0 0 0 4 // The last read read the final value of x, but the previous changes were not observed.
|
||||
0 0 0 0 // The write operation of x is not observed in the current time period, but the situation that x is 4 can be observed at some point in the future.
|
||||
```
|
||||
|
||||
### Memory Orders
|
||||
|
||||
In order to achieve the ultimate performance and achieve consistency of various strength requirements, C++11 defines six different memory sequences for atomic operations. The option `std::memory_order` expresses four synchronization models between multiple threads:
|
||||
To achieve the ultimate performance and achieve consistency of various strength requirements, C++11 defines six different memory sequences for atomic operations. The option `std::memory_order` expresses four synchronization models between multiple threads:
|
||||
|
||||
1. Relaxed model: Under this model, atomic operations within a single thread are executed sequentially, and instruction reordering is not allowed, but the order of atomic operations between different threads is arbitrary. The type is specified by `std::memory_order_relaxed`. Let's look at an example:
|
||||
|
||||
```cpp
|
||||
std::atomic<int> counter = {0};
|
||||
std::vector<std::thread> vt;
|
||||
for (int i = 0; i < 100; ++i) {
|
||||
vt.emplace_back([&](){
|
||||
counter.fetch_add(1, std::memory_order_relaxed);
|
||||
});
|
||||
}
|
||||
|
||||
for (auto& t : vt) {
|
||||
t.join();
|
||||
}
|
||||
std::cout << "current counter:" << counter << std::endl;
|
||||
```
|
||||
```cpp
|
||||
std::atomic<int> counter = {0};
|
||||
std::vector<std::thread> vt;
|
||||
for (int i = 0; i < 100; ++i) {
|
||||
vt.emplace_back([&](){
|
||||
counter.fetch_add(1, std::memory_order_relaxed);
|
||||
});
|
||||
}
|
||||
|
||||
for (auto& t : vt) {
|
||||
t.join();
|
||||
}
|
||||
std::cout << "current counter:" << counter << std::endl;
|
||||
```
|
||||
|
||||
2. Release/consumption model: In this model, we begin to limit the order of operations between processes. If a thread needs to modify a value, but another thread will have a dependency on that operation of the value, that is, the latter depends. former. Specifically, thread A has completed three writes to `x`, and thread `B` relies only on the third `x` write operation, regardless of the first two write behaviors of `x`, then `A ` When active `x.release()` (ie using `std::memory_order_release`), the option `std::memory_order_consume` ensures that `B` observes `A` when calling `x.load()` Three writes to `x`. Let's look at an example:
|
||||
|
||||
```cpp
|
||||
// initialize as nullptr to prevent consumer load a dangling pointer
|
||||
std::atomic<int*> ptr(nullptr);
|
||||
int v;
|
||||
std::thread producer([&]() {
|
||||
int* p = new int(42);
|
||||
v = 1024;
|
||||
ptr.store(p, std::memory_order_release);
|
||||
});
|
||||
std::thread consumer([&]() {
|
||||
int* p;
|
||||
while(!(p = ptr.load(std::memory_order_consume)));
|
||||
```cpp
|
||||
// initialize as nullptr to prevent consumer load a dangling pointer
|
||||
std::atomic<int*> ptr(nullptr);
|
||||
int v;
|
||||
std::thread producer([&]() {
|
||||
int* p = new int(42);
|
||||
v = 1024;
|
||||
ptr.store(p, std::memory_order_release);
|
||||
});
|
||||
std::thread consumer([&]() {
|
||||
int* p;
|
||||
while(!(p = ptr.load(std::memory_order_consume)));
|
||||
|
||||
std::cout << "p: " << *p << std::endl;
|
||||
std::cout << "v: " << v << std::endl;
|
||||
});
|
||||
producer.join();
|
||||
consumer.join();
|
||||
```
|
||||
std::cout << "p: " << *p << std::endl;
|
||||
std::cout << "v: " << v << std::endl;
|
||||
});
|
||||
producer.join();
|
||||
consumer.join();
|
||||
```
|
||||
|
||||
3. Release/Acquire model: Under this model, we can further tighten the order of atomic operations between different threads, specifying the timing between releasing `std::memory_order_release` and getting `std::memory_order_acquire`. **All** write operations before the release operation are visible to any other thread, ie, happens-before.
|
||||
3. Release/Acquire model: Under this model, we can further tighten the order of atomic operations between different threads, specifying the timing between releasing `std::memory_order_release` and getting `std::memory_order_acquire`. **All** write operations before the release operation is visible to any other thread, i.e., happens before.
|
||||
|
||||
As you can see, `std::memory_order_release` ensures that the write behavior after it does not occur before the release operation, which is a forward barrier, and`std::memory_order_acquire` ensures that its previous write behavior does not occur after this acquisition operation, there is a backward barrier. For the `std::memory_order_acq_rel` option, it combines the characteristics of the two and uniquely determines a memory barrier, so that the current thread's reading and writing of memory will not be rearranged before and after this operation.
|
||||
As you can see, `std::memory_order_release` ensures that the write behavior after it does not occur before the release operation, which is a forward barrier, and`std::memory_order_acquire` ensures that its previous write behavior does not occur after this acquisition operation, there is a backward barrier. For the `std::memory_order_acq_rel` option, combines the characteristics of the two and uniquely determines a memory barrier, so that the current thread's reading and writing of memory will not be rearranged before and after this operation.
|
||||
|
||||
Let's check an example:
|
||||
Let's check an example:
|
||||
|
||||
```cpp
|
||||
std::vector<int> v;
|
||||
std::atomic<int> flag = {0};
|
||||
std::thread release([&]() {
|
||||
v.push_back(42);
|
||||
flag.store(1, std::memory_order_release);
|
||||
});
|
||||
std::thread acqrel([&]() {
|
||||
int expected = 1; // must before compare_exchange_strong
|
||||
while(!flag.compare_exchange_strong(expected, 2, std::memory_order_acq_rel)) {
|
||||
expected = 1; // must after compare_exchange_strong
|
||||
}
|
||||
// flag has changed to 2
|
||||
});
|
||||
std::thread acquire([&]() {
|
||||
while(flag.load(std::memory_order_acquire) < 2);
|
||||
```cpp
|
||||
std::vector<int> v;
|
||||
std::atomic<int> flag = {0};
|
||||
std::thread release([&]() {
|
||||
v.push_back(42);
|
||||
flag.store(1, std::memory_order_release);
|
||||
});
|
||||
std::thread acqrel([&]() {
|
||||
int expected = 1; // must before compare_exchange_strong
|
||||
while(!flag.compare_exchange_strong(expected, 2, std::memory_order_acq_rel)) {
|
||||
expected = 1; // must after compare_exchange_strong
|
||||
}
|
||||
// flag has changed to 2
|
||||
});
|
||||
std::thread acquire([&]() {
|
||||
while(flag.load(std::memory_order_acquire) < 2);
|
||||
|
||||
std::cout << v.at(0) << std::endl; // must be 42
|
||||
});
|
||||
release.join();
|
||||
acqrel.join();
|
||||
acquire.join();
|
||||
```
|
||||
std::cout << v.at(0) << std::endl; // must be 42
|
||||
});
|
||||
release.join();
|
||||
acqrel.join();
|
||||
acquire.join();
|
||||
```
|
||||
|
||||
In this case we used `compare_exchange_strong`, which is the Compare-and-swap primitive, which has a weaker version, `compare_exchange_weak`, which allows a failure to be returned even if the exchange is successful. The reason is due to a false failure on some platforms, specifically, when the CPU performs a context switch, another thread loads the same address to produce an inconsistency. In addition, the performance of `compare_exchange_strong` may be slightly worse than `compare_exchange_weak`, but in most cases, `compare_exchange_strong` should be limited.
|
||||
In this case we used `compare_exchange_strong`, which is the Compare-and-swap primitive, which has a weaker version, `compare_exchange_weak`, which allows a failure to be returned even if the exchange is successful. The reason is due to a false failure on some platforms, specifically when the CPU performs a context switch, another thread loads the same address to produce an inconsistency. In addition, the performance of `compare_exchange_strong` may be slightly worse than `compare_exchange_weak`, but in most cases, `compare_exchange_strong` should be limited.
|
||||
|
||||
4. Sequential Consistent Model: Under this model, atomic operations satisfy sequence consistency, which in turn can cause performance loss. It can be specified explicitly by `std::memory_order_seq_cst`. Let's look a final example:
|
||||
4. Sequential Consistent Model: Under this model, atomic operations satisfy sequence consistency, which in turn can cause performance loss. It can be specified explicitly by `std::memory_order_seq_cst`. Let's look at a final example:
|
||||
|
||||
```cpp
|
||||
std::atomic<int> counter = {0};
|
||||
std::vector<std::thread> vt;
|
||||
for (int i = 0; i < 100; ++i) {
|
||||
vt.emplace_back([&](){
|
||||
counter.fetch_add(1, std::memory_order_seq_cst);
|
||||
});
|
||||
}
|
||||
```cpp
|
||||
std::atomic<int> counter = {0};
|
||||
std::vector<std::thread> vt;
|
||||
for (int i = 0; i < 100; ++i) {
|
||||
vt.emplace_back([&](){
|
||||
counter.fetch_add(1, std::memory_order_seq_cst);
|
||||
});
|
||||
}
|
||||
|
||||
for (auto& t : vt) {
|
||||
t.join();
|
||||
}
|
||||
std::cout << "current counter:" << counter << std::endl;
|
||||
```
|
||||
|
||||
This example is essentially the same as the first loose model example. Just change the memory order of the atomic operation to `memory_order_seq_cst`. Interested readers can write their own programs to measure the performance difference caused by these two different memory sequences.
|
||||
for (auto& t : vt) {
|
||||
t.join();
|
||||
}
|
||||
std::cout << "current counter:" << counter << std::endl;
|
||||
```
|
||||
|
||||
This example is essentially the same as the first loose model example. Just change the memory order of the atomic operation to `memory_order_seq_cst`. Interested readers can write their own programs to measure the performance difference caused by these two different memory sequences.
|
||||
|
||||
## Conclusion
|
||||
|
||||
The C++11 language layer provides support for concurrent programming. This section briefly introduces `std::thread`/`std::mutex`/`std::future`, an important tool that can't be avoided in concurrent programming.
|
||||
In addition, we also introduced the "memory model" as one of the most important features of C++11.
|
||||
They provide an critical foundation for standardized high performance computing for C++.
|
||||
They provide a critical foundation for standardized high-performance computing for C++.
|
||||
|
||||
## Exercises
|
||||
|
||||
1. Write a simple thread pool that provides the following features:
|
||||
|
||||
```cpp
|
||||
ThreadPool p(4); // specify four work thread
|
||||
```cpp
|
||||
ThreadPool p(4); // specify four work thread
|
||||
|
||||
// enqueue a task, and return a std::future
|
||||
auto f = pool.enqueue([](int life) {
|
||||
return meaning;
|
||||
}, 42);
|
||||
// enqueue a task, and return a std::future
|
||||
auto f = pool.enqueue([](int life) {
|
||||
return meaning;
|
||||
}, 42);
|
||||
|
||||
// fetch result from future
|
||||
std::cout << f.get() << std::endl;
|
||||
```
|
||||
// fetch result from future
|
||||
std::cout << f.get() << std::endl;
|
||||
```
|
||||
|
||||
2. Use `std::atomic<bool>` to implement a mutex.
|
||||
|
||||
|
||||
@@ -12,22 +12,20 @@ order: 9
|
||||
|
||||
### `long long int`
|
||||
|
||||
`long long int` is not the first to be introduced in C++11.
|
||||
In fact, as early as C99, `long long int` has been included in the C standard,
|
||||
so most compilers already support it.
|
||||
C++11 now formally incorporate it into the standard library,
|
||||
`long long int` is not the first to be introduced in C++11.
|
||||
As early as C99, `long long int` has been included in the C standard,
|
||||
so most compilers already support it.
|
||||
C++11 now formally incorporate it into the standard library,
|
||||
specifying a `long long int` type with at least 64 bits.
|
||||
|
||||
## 9.2 `noexcept` and Its Operations
|
||||
|
||||
One of the big advantages of C++ over C is that
|
||||
C++ itself defines a complete set of exception handling mechanisms.
|
||||
However, before C++11, almost no one used to write
|
||||
an exception declaration expression after the function name.
|
||||
Starting from C++11, this mechanism was deprecated,
|
||||
so we will not discuss or introduce the previous mechanism.
|
||||
How to work and how to use it, you should not take the initiative
|
||||
to understand it.
|
||||
One of the big advantages of C++ over C is that
|
||||
C++ itself defines a complete set of exception handling mechanisms.
|
||||
However, before C++11, almost no one used to write an exception declaration expression after the function name.
|
||||
Starting from C++11, this mechanism was deprecated,
|
||||
so we will not discuss or introduce the previous mechanism.
|
||||
How to work and how to use it, you should not take the initiative to understand it.
|
||||
|
||||
C++11 simplifies exception declarations into two cases:
|
||||
|
||||
@@ -41,13 +39,13 @@ void may_throw(); // May throw any exception
|
||||
void no_throw() noexcept; // Cannot throw any exception
|
||||
```
|
||||
|
||||
If a function modified with `noexcept` is thrown,
|
||||
the compiler will use `std::terminate()` to
|
||||
If a function modified with `noexcept` is thrown,
|
||||
the compiler will use `std::terminate()` to
|
||||
immediately terminate the program.
|
||||
|
||||
`noexcept` can also be used as an operator to manipulate an expression.
|
||||
When the expression has no exception, it returns `true`,
|
||||
otherwise it returns `false`.
|
||||
`noexcept` can also be used as an operator to manipulate an expression.
|
||||
When the expression has no exception, it returns `true`,
|
||||
otherwise, it returns `false`.
|
||||
|
||||
```cpp
|
||||
#include <iostream>
|
||||
@@ -75,8 +73,8 @@ int main()
|
||||
}
|
||||
```
|
||||
|
||||
`noexcept` can modify the function of blocking exceptions
|
||||
after modifying a function. If an exception is generated internally,
|
||||
`noexcept` can modify the function of blocking exceptions
|
||||
after modifying a function. If an exception is generated internally,
|
||||
the external will not trigger. For instance:
|
||||
|
||||
```cpp
|
||||
@@ -108,13 +106,13 @@ exception captured, from non_block_throw()
|
||||
|
||||
### Raw String Literal
|
||||
|
||||
In traditional C++, it is very painful to write a string full of
|
||||
special characters. For example, a string containing HTML ontology
|
||||
needs to add a large number of escape characters.
|
||||
In traditional C++, it is very painful to write a string full of
|
||||
special characters. For example, a string containing HTML ontology
|
||||
needs to add a large number of escape characters.
|
||||
For example, a file path on Windows often as: `C:\\Path\\To\\File`.
|
||||
|
||||
C++11 provides the original string literals,
|
||||
which can be decorated with `R` in front of a string,
|
||||
C++11 provides the original string literals,
|
||||
which can be decorated with `R` in front of a string,
|
||||
and the original string is wrapped in parentheses, for example:
|
||||
|
||||
```cpp
|
||||
@@ -130,7 +128,7 @@ int main() {
|
||||
|
||||
### Custom Literal
|
||||
|
||||
C++11 introduces the ability to customize literals by
|
||||
C++11 introduces the ability to customize literals by
|
||||
overloading the double quotes suffix operator:
|
||||
|
||||
```cpp
|
||||
@@ -190,19 +188,19 @@ int main() {
|
||||
}
|
||||
```
|
||||
|
||||
where `std::max_align_t` requires exactly the same alignment for each scalar type, so it has almost no difference in maximum scalars.
|
||||
where `std::max_align_t` requires the same alignment for each scalar type, so it has almost no difference in maximum scalars.
|
||||
In turn, the result on most platforms is `long double`, so the alignment requirement for `AlignasStorage` we get here is 8 or 16.
|
||||
|
||||
## Conclusion
|
||||
|
||||
Several of the features introduced in this section are those that
|
||||
use more frequent features from modern C++ features that
|
||||
have not yet been introduced. `noexcept` is the most important feature.
|
||||
One of its features is to prevent the spread of anomalies,
|
||||
Several of the features introduced in this section are those that
|
||||
use more frequent features from modern C++ features that
|
||||
have not yet been introduced. `noexcept` is the most important feature.
|
||||
One of its features is to prevent the spread of anomalies,
|
||||
effective Let the compiler optimize our code to the maximum extent possible.
|
||||
|
||||
[Table of Content](./toc.md) | [Previous Chapter](./08-filesystem.md) | [Next Chapter: Outlook: Introduction of C++20](./10-cpp20.md)
|
||||
|
||||
## Licenses
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
|
||||
@@ -9,22 +9,22 @@ order: 10
|
||||
[TOC]
|
||||
|
||||
C++20 seems to be an exciting update.
|
||||
For example, as early as C++11, the `Concept`,
|
||||
For example, as early as C++11, the `Concept`,
|
||||
which was eager to call for high-altitude but ultimately lost, is now on the line.
|
||||
The C++ Organizing Committee decided to vote to finalize C++20 with many proposals,
|
||||
The C++ Organizing Committee decided to vote to finalize C++20 with many proposals,
|
||||
such as **Concepts**/**Module**/**Coroutine**/**Ranges**/ and so on.
|
||||
In this chapter we'll take a look at some of the important features that
|
||||
In this chapter, we'll take a look at some of the important features that
|
||||
C++20 will introduce.
|
||||
|
||||
## Concept
|
||||
|
||||
Concept is a further enhancement to C++ template programming.
|
||||
The concept is a further enhancement to C++ template programming.
|
||||
In simple terms, the concept is a compile-time feature.
|
||||
It allows the compiler to evaluate template parameters at compile time,
|
||||
It allows the compiler to evaluate template parameters at compile-time,
|
||||
greatly enhancing our experience with template programming in C++.
|
||||
When programming with templates, we often encounter a variety of heinous errors.
|
||||
This is because we have so far been unable to check and limit template parameters.
|
||||
For example, the following two lines of code can cause a lot of
|
||||
For example, the following two lines of code can cause a lot of
|
||||
almost unreadable compilation errors:
|
||||
|
||||
```cpp
|
||||
@@ -37,12 +37,12 @@ int main() {
|
||||
}
|
||||
```
|
||||
|
||||
The root cause of this code error is that `std::sort` must provide
|
||||
a random iterator for the sorting container, otherwise it will not be used,
|
||||
The root cause of this code error is that `std::sort` must provide
|
||||
a random iterator for the sorting container, otherwise it will not be used,
|
||||
and we know that `std::list` does not support random access.
|
||||
In the conceptual language, the iterator in `std::list` does not satisfy
|
||||
In the conceptual language, the iterator in `std::list` does not satisfy
|
||||
the constraint of the concept of random iterators in `std::sort`.
|
||||
After introducing the concept, we can constrain the template parameters
|
||||
After introducing the concept, we can constrain the template parameters
|
||||
like this:
|
||||
|
||||
```cpp
|
||||
@@ -99,4 +99,4 @@ This is still full of charm for a programming language that is already in its th
|
||||
|
||||
## Licenses
|
||||
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
<a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-nc-nd/4.0/88x31.png" /></a><br />This work was written by [Ou Changkun](https://changkun.de) and licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License</a>. The code of this repository is open sourced under the [MIT license](../../LICENSE).
|
||||
|
||||
Reference in New Issue
Block a user