mirror of
https://github.com/CnTransGroup/EffectiveModernCppChinese.git
synced 2025-01-30 22:00:30 +08:00
Merge pull request #79 from icgw/cguowei
Update item24.md: modify some statements and format style
This commit is contained in:
commit
5886d338fd
@ -18,9 +18,9 @@ template<typename T>
|
||||
void f(T&& param); //不是右值引用
|
||||
```
|
||||
|
||||
事实上,“`T&&`”有两种不同的意思。第一种,当然是右值引用。这种引用表现得正如你所期待的那样:它们只绑定到右值上,并且它们主要的存在原因就是为了声明某个对象可以被移动。
|
||||
事实上,“`T&&`”有两种不同的意思。第一种,当然是右值引用。这种引用表现得正如你所期待的那样:它们只绑定到右值上,并且它们主要的存在原因就是为了识别可以移动操作的对象。
|
||||
|
||||
“`T&&`”的第二层意思,是它既可以是一个右值引用,也可以是一个左值引用。这种引用在源码里看起来像右值引用(也即“`T&&`”),但是它们可以表现得像是左值引用(也即“`T&`”)一样。它们的二重性使它们既可以绑定到右值上(就像右值引用),也可以绑定到左值上(就像左值引用)。 此外,它们还可以绑定到`const`或者non-`const`的对象上,也可以绑定到`volatile`或者non-`volatile`的对象上,甚至可以绑定到既`const`又`volatile`的对象上。它们可以绑定到几乎任何东西。这种空前灵活的引用值得拥有自己的名字。我把它叫做**通用引用**(*universal references*)。([Item25](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item25.md)解释了`std::forward`几乎总是可以应用到通用引用上,并且在这本书即将出版之际,一些C++社区的成员已经开始将这种通用引用称之为**转发引用**(*forwarding references*))。
|
||||
“`T&&`”的另一种意思是,它既可以是右值引用,也可以是左值引用。这种引用在源码里看起来像右值引用(即“`T&&`”),但是它们可以表现得像是左值引用(即“`T&`”)。它们的二重性使它们既可以绑定到右值上(就像右值引用),也可以绑定到左值上(就像左值引用)。 此外,它们还可以绑定到`const`或者non-`const`的对象上,也可以绑定到`volatile`或者non-`volatile`的对象上,甚至可以绑定到既`const`又`volatile`的对象上。它们可以绑定到几乎任何东西。这种空前灵活的引用值得拥有自己的名字。我把它叫做**通用引用**(*universal references*)。([Item25](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item25.md)解释了`std::forward`几乎总是可以应用到通用引用上,并且在这本书即将出版之际,一些C++社区的成员已经开始将这种通用引用称之为**转发引用**(*forwarding references*))。
|
||||
|
||||
在两种情况下会出现通用引用。最常见的一种是函数模板形参,正如在之前的示例代码中所出现的例子:
|
||||
|
||||
@ -58,21 +58,21 @@ f(std::move(w)); //传递给f一个右值;param的类型会是
|
||||
//Widget&&,即右值引用
|
||||
```
|
||||
|
||||
对一个通用引用而言,类型推导是必要的,但是它还不够。声明引用的**格式**必须正确,并且这种格式是被限制的。它必须是准确的“`T&&`”。再看看之前我们已经看过的代码示例:
|
||||
对一个通用引用而言,类型推导是必要的,但是它还不够。引用声明的**形式**必须正确,并且该形式是被限制的。它必须恰好为“`T&&`”。再看看之前我们已经看过的代码示例:
|
||||
|
||||
```cpp
|
||||
template <typename T>
|
||||
void f(std::vector<T>&& param); //param是一个右值引用
|
||||
```
|
||||
|
||||
当函数`f`被调用的时候,类型`T`会被推导(除非调用者显式地指定它,这种边缘情况我们不考虑)。但是`param`的类型声明并不是`T&&`,而是一个`std::vector<T>&&`。这排除了`param`是一个通用引用的可能性。`param`因此是一个右值引用——当你向函数`f`传递一个左值时,你的编译器将会开心地帮你确认这一点:
|
||||
当函数`f`被调用的时候,类型`T`会被推导(除非调用者显式地指定它,这种边缘情况我们不考虑)。但是`param`的类型声明并不是`T&&`,而是一个`std::vector<T>&&`。这排除了`param`是一个通用引用的可能性。`param`因此是一个右值引用——当你向函数`f`传递一个左值时,你的编译器将会乐于帮你确认这一点:
|
||||
|
||||
```cpp
|
||||
std::vector<int> v;
|
||||
f(v); //错误!不能将左值绑定到右值引用
|
||||
```
|
||||
|
||||
即使是出现一个简单的`const`修饰符,也足以使一个引用失去成为通用引用的资格:
|
||||
即使一个简单的`const`修饰符的出现,也足以使一个引用失去成为通用引用的资格:
|
||||
|
||||
```cpp
|
||||
template <typename T>
|
||||
@ -108,7 +108,7 @@ public:
|
||||
|
||||
现在你可以清楚地看到,函数`push_back`不包含任何类型推导。`push_back`对于`vector<T>`而言(有两个函数——它被重载了)总是声明了一个类型为rvalue-reference-to-`T`的形参。
|
||||
|
||||
相反,`std::vector`内部的概念上相似的成员函数`emplace_back`,却确实包含类型推导:
|
||||
作为对比,`std::vector`内的概念上相似的成员函数`emplace_back`,却确实包含类型推导:
|
||||
|
||||
```cpp
|
||||
template<class T, class Allocator = allocator<T>> //依旧来自C++标准
|
||||
@ -120,16 +120,16 @@ public:
|
||||
};
|
||||
```
|
||||
|
||||
这儿,类型参数(*type parameter*)`Args`是独立于`vector`的类型参数`T`之外的,所以`Args`会在每次`emplace_back`被调用的时候被推导。(好吧,`Args`实际上是一个[*parameter pack*](https://en.cppreference.com/w/cpp/language/parameter_pack),而不是一个类型参数,但是为了讨论之利,我们可以把它当作是一个类型参数。)
|
||||
这儿,类型参数(*type parameter*)`Args`是独立于`vector`的类型参数`T`的,所以`Args`会在每次`emplace_back`被调用的时候被推导。(好吧,`Args`实际上是一个[*parameter pack*](https://en.cppreference.com/w/cpp/language/parameter_pack),而不是一个类型参数,但是为了方便讨论,我们可以把它当作是一个类型参数。)
|
||||
|
||||
虽然函数`emplace_back`的类型参数被命名为`Args`,但是它仍然是一个通用引用,这补充了我之前所说的,通用引用的格式必须是“`T&&`”。 没有任何规定必须使用名字`T`。举个例子,如下模板接受一个通用引用,因为格式(“`type&&`”)是正确的,并且`param`的类型将会被推导(重复一次,不考虑边缘情况,也即当调用者明确给定类型的时候)。
|
||||
虽然函数`emplace_back`的类型参数被命名为`Args`,但是它仍然是一个通用引用,这补充了我之前所说的,通用引用的格式必须是“`T&&`”。你使用的名字`T`并不是必要的。举个例子,如下模板接受一个通用引用,因为形式(“`type&&`”)是正确的,并且`param`的类型将会被推导(重复一次,不考虑边缘情况,即当调用者明确给定类型的时候)。
|
||||
|
||||
```cpp
|
||||
template<typename MyTemplateType> //param是通用引用
|
||||
void someFunc(MyTemplateType&& param);
|
||||
```
|
||||
|
||||
我之前提到,类型为`auto`的变量可以是通用引用。更准确地说,类型声明为`auto&&`的变量是通用引用,因为会发生类型推导,并且它们满足正确的格式要求(`T&&`)。`auto`类型的通用引用不如函数模板形参中的通用引用常见,但是它们在C++11中常常突然出现。而它们在C++14中出现得更多,因为C++14的*lambda*表达式可以声明`auto&&`类型的形参。举个例子,如果你想写一个C++14标准的*lambda*表达式,来记录任意函数调用花费的时间,你可以这样:
|
||||
我之前提到,类型为`auto`的变量可以是通用引用。更准确地说,类型声明为`auto&&`的变量是通用引用,因为会发生类型推导,并且它们具有正确形式(`T&&`)。`auto`类型的通用引用不如函数模板形参中的通用引用常见,但是它们在C++11中常常突然出现。而它们在C++14中出现得更多,因为C++14的*lambda*表达式可以声明`auto&&`类型的形参。举个例子,如果你想写一个C++14标准的*lambda*表达式,来记录任意函数调用的时间开销,你可以这样写:
|
||||
|
||||
```cpp
|
||||
auto timeFuncInvocation =
|
||||
@ -143,9 +143,9 @@ auto timeFuncInvocation =
|
||||
};
|
||||
```
|
||||
|
||||
如果你对*lambda*里的代码“`std::forward<decltype(blah blah blah)>`”反应是“这什么鬼...?!”,这只代表着你可能还没有读[Item33](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/6.LambdaExpressions/item33.md)。别担心。在本条款,重要的事是*lambda*表达式中声明的`auto&&`类型的形参。`func`是一个通用引用,可以被绑定到任何可调用对象,无论左值还是右值。`args`是0个或者多个通用引用(也就是说,它是个通用引用*parameter pack*),它可以绑定到任意数目、任意类型的对象上。多亏了`auto`类型的通用引用,函数`timeFuncInvocation`可以对**近乎任意**(pretty much any)函数进行计时。(如果你想知道任意(any)和近乎任意(pretty much any)的区别,往后翻到[Item30](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item30.md))。
|
||||
如果你对*lambda*里的代码“`std::forward<decltype(blah blah blah)>`”反应是“这是什么鬼...?!”,只能说你可能还没有读[Item33](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/6.LambdaExpressions/item33.md)。别担心。在本条款,重要的事是*lambda*表达式中声明的`auto&&`类型的形参。`func`是一个通用引用,可以被绑定到任何可调用对象,无论左值还是右值。`args`是0个或者多个通用引用(即它是个通用引用*parameter pack*),它可以绑定到任意数目、任意类型的对象上。多亏了`auto`类型的通用引用,函数`timeFuncInvocation`可以对**近乎任意**(pretty much any)函数进行计时。(如果你想知道任意(any)和近乎任意(pretty much any)的区别,往后翻到[Item30](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item30.md))。
|
||||
|
||||
牢记整个本条款——通用引用的基础——是一个谎言,啊,一个“抽象”。隐藏在其底下的真相被称为**引用折叠**(*reference collapsing*),[Item28](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item28.md)致力于讨论它。但是这个真相并不降低该抽象的有用程度。区分右值引用和通用引用将会帮助你更准确地阅读代码(“究竟我眼前的这个`T&&`是只绑定到右值还是可以绑定任意对象呢?”),并且,当你在和你的合作者交流时,它会帮助你避免歧义(“在这里我在用一个通用引用,而非右值引用……”)。它也可以帮助你弄懂[Item25](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item25.md)和[26](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item26.md),它们依赖于右值引用和通用引用的区别。所以,拥抱这份抽象,陶醉于它吧。就像牛顿的力学定律(本质上不正确),比起爱因斯坦的广义相对论(这是真相)而言,往往更简单,更易用。所以这份通用引用的概念,相较于穷究引用折叠的细节而言,是更合意之选。
|
||||
牢记整个本条款——通用引用的基础——是一个谎言,噢不,是一个“抽象”。其底层真相被称为**引用折叠**(*reference collapsing*),[Item28](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item28.md)的专题将致力于讨论它。但是这个真相并不降低该抽象的有用程度。区分右值引用和通用引用将会帮助你更准确地阅读代码(“究竟我眼前的这个`T&&`是只绑定到右值还是可以绑定任意对象呢?”),并且,当你在和你的合作者交流时,它会帮助你避免歧义(“在这里我在用一个通用引用,而非右值引用”)。它也可以帮助你弄懂[Item25](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item25.md)和[26](https://github.com/kelthuzadx/EffectiveModernCppChinese/blob/master/5.RRefMovSemPerfForw/item26.md),它们依赖于右值引用和通用引用的区别。所以,拥抱这份抽象,陶醉于它吧。就像牛顿的力学定律(本质上不正确),比起爱因斯坦的广义相对论(这是真相)而言,往往更简单,更易用。所以通用引用的概念,相较于穷究引用折叠的细节而言,是更合意之选。
|
||||
|
||||
**请记住:**
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user