英文出处： Bjarne Stroustrup。欢迎加入 翻译小组。
[编注：为了增加您冬天阅读的乐趣，我们很荣幸的奉上Bjarne Stroustrup大神的这个包含3个部分的系列文章。第一部分在这里；第三部分将在下个周一发布，即在圣诞节之前完成这个系列。请欣赏。]
1. 简介
本系列包括 3 篇文章，我将向大家展示并澄清关于C++的五个普遍的误解：
- 1. “要理解C++，你必须先学习C”
- 2. “C++是一门面向对象的语言”
- 3. “为了软件可靠性，你需要垃圾回收”
- 4. “为了效率，你必须编写底层代码”
- 5. “C++只适用于大型、复杂的程序”
如果你深信上述误解中的任何一个，或者有同事深信不疑，那么这篇短文正是为你而写。对某些人，某些任务，在某些时间，其中一些误解曾经只是正确的。然而，在如今的C++，应用广泛使用的最先进的ISO C++ 2011编译器和工具，它们只是误解。
我认为这些误解是“普遍的”，是因为我经常听到。偶尔，它们有原因来支持，但是它们经常地被作为明显的、不需要理由的支持地表达出来。有时，它们成为某些场景下不考虑使用C++的理由。
每一个误解，都需要一大篇文章，甚至一本书来澄清，但是这里我的目标很简单，就是抛出问题，并简明地陈述我的原因。
前两个误解在我的第一篇文中呈现。
4. 误解3：“对可靠的软件，你需要垃圾回收”
在回收不再使用的内存上，垃圾回收做的很好，但是并不完美。它并非灵丹妙药。因为内存可以被间接地引用，并且很多资源并不是普通内存。考虑：
|
1
2
3
4
5
6
7
8
9
10
|
class
Filter {
// take input from file iname and produce output on file oname
public
:
Filter(
const
string& iname,
const
string& oname);
// constructor
~Filter();
// destructor
// ...
private
:
ifstream is;
ofstream os;
// ...
};
|
Filter的构造函数打开了两个文件。之后，Filter从它的输入文件读取数据，执行一些任务，然后输出到输出文件。任务与Filter直接有关，可能通过一个lambda提供，或者通过一个函数返回重载了虚方法的继承类来提供；这些细节在资源管理的讨论中并不重要。我们可以这样创建Filter：
|
1
2
3
4
5
6
7
|
void
user()
{
Filter flt {“books”,”authors”};
Filter* p =
new
Filter{“novels”,”favorites”};
// use flt and *p
delete
p;
}
|
从资源管理的观点来看，这里的问题在于如何保证关闭被打开的文件，以及回收这两个流对象的相关资源，以供后续重复使用。
对于依赖垃圾回收的语言和系统，常规的解决方法是消除delete（它很容易被遗忘，导致泄漏）和析构函数（因为支持垃圾回收的语言很少有析构函数，而最好避免使用“finalizers”，因为它在逻辑上容易被取巧，并经常损坏性能）。内存回收器能够回收所有内存，但是我们需要用户手动（代码）关闭文件，以及释放与流相关的非内存资源（如锁）。因此，内存是自动（此例中很完美）回收的，但是需要手动管理其他资源，从而存在错误和泄露的可能性。
C++中常用和推荐的方法是使用析构函数，来保证资源被回收。典型的，在此例和通用技术中，这类资源在构造器中申请，并遵循有着笨拙名字的“资源申请即初始化”（RAII）原则。在user()中，flt的析构函数隐式地调用了流is和os的析构函数。这些析构函数依次关闭文件并释放流相关的资源。delete对*p做同样的操作。
有经验的现代C++11用户会注意到，user()相当笨拙并容易出错。这样会更好一些：
|
1
2
3
4
5
6
|
void
user2()
{
Filter flt {“books”,”authors”};
unique_ptr
new
Filter{“novels”,”favorites”}};
// use flt and *p
}
|
现在当user()退出时，*p将被隐式地释放。程序员不会忘记这么做。unique_ptr是标准库类，它被设计用来在没有运行时（RTTI）或者空间开销的前提下，增强内置“裸“指针的资源释放。
然而，我们仍然可以看到new，这个解决方案有点啰嗦（Filter类型重复了两次），并且将普通指针构造（通过new）和智能指针（这里是unique_ptr）分离开阻止了一些有效的优化。我们可以使用C++14中的辅助函数make_unique来改进，它构造一个指定类型的对象，并返回一个unique_ptr：
|
1
2
3
4
5
6
|
void
user3()
{
Filter flt {“books”,”authors”};
auto p = make_unique
// use flt and *p
}
|
Unless we really needed the second Filter to have pointer semantics (which is unlikely) this would be better still:
除非我们在语法上真正地需要第二个Filter指针（这不太可能），否则这样会更好：
|
1
2
3
4
5
6
|
void
user3()
{
Filter flt {“books”,”authors”};
Filter flt2 {“novels”,”favorites”};
// use flt and flt2
}
|
最后一个版本比最初的代码更简短，更简单，更清晰，更快。
但是Filter的析构函数做什么？它释放Filter拥有的资源；即，它关闭文件（通过触发它们的析构函数）。实际上，这是隐式完成的，因此除非有其他需要，我们可以忽略Filter析构函数的显式声明，让编译器来处理它。因此，我需要编写的只有：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
class
Filter {
// take input from file iname and produce output on file oname
public
:
Filter(
const
string& iname,
const
string& oname);
// ...
private
:
ifstream is;
ofstream os;
// ...
};
void
user3()
{
Filter flt {“books”,”authors”};
Filter flt2 {“novels”,”favorites”};
// use flt and flt2
}
|
这比你在多数垃圾回收语言（如Java或C#）中写的代码更简单；并且对那些健忘的程序员，它不会导致泄漏。它也比其他方案（不需要使用free/dynamic，也不需要运行垃圾回收器）更快。典型的，相对与手动方式，RAII也缩短了资源的生命周期。
这是我理想的资源管理方式。它不单单处理内存，同时也处理通用（非内存）资源，例如文件句柄，线程句柄和锁。但是这就够了吗？怎么处理需要从一个函数传递到另一个函数的对象？那些没有明显单独拥有者的对象呢？
4.1传递拥有关系：move
让我们先来看一看把对象从一个代码块传递到另一个代码块的问题。关键问题是，在不复制或者错误使用指针导致严重性能问题的前提下，如何从一个代码块中得到大量信息。使用指针的传统方式是：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
X* make_X()
{
X* p =
new
X:
// ... fill X ..
return
p;
}
void
user()
{
X* q = make_X();
// ... use *q ...
delete
q;
}
|
现在，谁有责任来释放对象呢？在这个简单的例子里，明显是make_X()的调用者，但是通常情况下答案并不是显而易见的。假如make_X()为了最小化申请负荷而保存了对象的缓存呢？假如user()把指针传递给了其他如other_user()函数呢？潜在的可能性很多，在这类程序中的泄露并非罕见。
我可能会使用一个shared_ptr或者unique_ptr，来明确表明对创建对象的拥有关系。例如：
|
1
|
unique_ptr
|
但是为什么要使用一个指针（不管是否智能）呢？通常，我不想使用指针；并且，指针会导致从对象的常规使用中分心。例如，一个矩阵求和函数，根据两个参数创建了一个新的对象（求和结果），但是返回一个指针会导致非常奇怪的代码：
|
1
2
|
unique_prt
const
Matrix& a,
const
Matrix& b);
Matrix res = *(a+b);
|
这里需要使用*操作符来得到求和结果，否则得到的是指向结果的指针。在很多情况下，我真正需要的是一个对象，而不是指向对象的指针。很多时候，我可以容易地做到。尤其是，复制一个小的对象很快，我不想使用指针：
|
1
2
|
double
sqrt
(
double
);
// a square root function
double
s2 =
sqrt
(2);
// get the square root of 2
|
从另一方面来说，一个包含了很多数据的对象，一般会处理这么多的数据。考虑istream，string，vector，list和thread。它们都只包含了少数几个字节的数据，来保证潜在的大量数据访问。再次考虑矩阵求和。我们需要的是
|
1
2
|
Matrix operator+(
const
Matrix& a,
const
Matrix& b);
// return the sum of a and b
Matrix r = x+y;
|
我们可以轻松的做到。
|
1
2
3
4
5
6
|
Matrix operator+(
const
Matrix& a,
const
Matrix& b)
{
Matrix res;
// ... fill res with element sums ...
return
res;
}
|
默认情况下，它将res的元素复制给r，但是因为res即将被销毁，保存元素的内存即将被释放，因此这里没有必要复制：我们可以“窃取”元素。自从C++诞生以来，任何人都可能这么做，并且很多人确实这么做了。但是这是代码实现的技巧，而且这项技术并不好理解。C++11直接支持“窃取表示法（stealing the representation）”，通过move操作传递一个句柄的拥有关系。考虑一个简单的2维double类型的矩阵：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
class
Matrix {
double
* elem;
// pointer to elements
int
nrow;
// number of rows
int
ncol;
// number of columns
public
:
Matrix(
int
nr,
int
nc)
// constructor: allocate elements
:elem{
double
[nr*nc]}, nrow{nr}, ncol{nc}
{
for
(
int
i=0; i
}
Matrix(
const
Matrix&);
// copy constructor
Matrix operator=(
const
Matrix&);
// copy assignment
Matrix(Matrix&&);
// move constructor
Matrix operator=(Matrix&&);
// move assignment
~Matrix() {
delete
[] elem; }
// destructor: free the elements
// …
};
|
通过引用参数(&)，可以识别一个复制操作。类似地，通过右值引用(&&)参数，可以识别一个move操作。move操作的目的是“窃取”对象表现，并留下一个“空对象”。对Matrix，意味着这样的情形：
|
1
2
3
4
5
|
Matrix::Matrix(Matrix&& a)
// move constructor
:nrow{a.nrow}, ncol{a.ncol}, elem{a.elem}
// “steal” the representation
{
a.elem = nullptr;
// leave “nothing” behind
}
|
就是这样！当编译器看到返回值res，它意识到res即将被销毁。即，在函数返回后res将不再被使用。因此它使用了一个move构造函数来传递返回值，而不是复制构造函数。特殊的，对于
|
1
|
Matrix r = a+b;
|
在operator+()内部的res变成了空——析构函数将空执行一次——然后r拥有了res的元素。我们成功地从函数的结果中取得了元素——可能是数M字节的内存——并存入调用函数的变量中。我们用最小的代价实现了（可能是4个字的赋值）。
老练的C++用户指出，一个好的编译器能够完全消除返回值复制操作（这个例子中是，消除掉4个字的赋值和析构函数调用）。然而，这是依赖于实现的，我不喜欢我的基本编程技术的性能依赖于独立编译器的聪明程度。更进一步，一个能够消除复制的编译器，也能够轻易的消除move。这里我们所拥有的，是一个简单、可靠和通用的方式，能够消除从一个代码块移动大量信息到另一个块的复杂度和代价。
通常，我们甚至不需要定义所有这些赋值和移动操作。如果一个类由拥有特定表现的成员组成，我们可以简单地依赖编译器自动生成的默认操作。考虑：
|
1
2
3
4
5
6
7
8
9
10
11
|
class
Matrix {
vector<
double
> elem;
// elements
int
nrow;
// number of rows
int
ncol;
// number of columns
public
:
Matrix(
int
nr,
int
nc)
// constructor: allocate elements
:elem(nr*nc), nrow{nr}, ncol{nc}
{ }
// ...
};
|
这个版本的Matrix和之前版本的表现相同，除了它处理错误稍好一些，以及稍大一些（一个vector通常是3个字）。
不是句柄的对象怎么处理呢？如果它们很小，像int，或者complex，不用担心。否则，把它们改成句柄，或者使用“智能”指针返回，如unique_ptr和shared_ptr。不要和“裸”操作new和delete混用。
不幸的是，类似我上面例子中的Matrix类不是ISO C++标准库的一部分，但是还是可以找到的（开源或者商业）。例如，在网上搜索“Origin Matrix Sutton”，阅读我The C++ Programming Language (Fourth Edition)的第29章，里面有如何设计类似矩阵类的讨论。
4.2 共享拥有关系：shared_ptr
在关于垃圾回收的讨论中，通常会注意到一个现象，即不是每一个对象都有唯一的拥有者。这意味着，我们必须确保当最后一个引用消除后，才能销毁/释放这个对象。在这个模型中，我们必须有一个机制，来保证当对象的最后一个拥有者销毁时，销毁这个对象。即，我们需要一种共享的拥有关系形式。假设我们有一个同步的队列，sync_queue，用作任务之间的通信。生产者和消费者都拥有一个指向sync_queue的指针：
|
1
2
3
4
5
6
7
8
|
void
startup()
{
sync_queue* p =
new
sync_queue{200};
// trouble ahead!
thread
t1 {task1,iqueue,p};
// task1 reads from *iqueue and writes to *p
thread
t2 {task2,p,oqueue};
// task2 reads from *p and writes to *oqueue
t1.detach();
t2.detach();
}
|
我假定task1，task2，iqueue和oqueue已经在其他地方定义好了；很抱歉让线程的生存周期比创建线程的域更长（使用detatch()）。你可能会想到多任务处理中的管道和同步队列。然而，这里我只对一个问题感兴趣：“谁来释放startup()中创建的sync_queue？”。如前面所写，只有一个正确答案：“最后使用sync_queue的那个线程”。这是一个刺激产生垃圾回收的经典情形。垃圾回收的最初形式是引用计数：保持对象被使用的计数，当计数降为0时，释放对象。今天很多语言都依赖于这种想法，而C++11通过shared_ptr的形式支持它。例子变成这样：
|
1
2
3
4
5
6
7
8
|
void
startup()
{
auto p = make_shared
// make a sync_queue and return a stared_ptr to it
thread
t1 {task1,iqueue,p};
// task1 reads from *iqueue and writes to *p
thread
t2 {task2,p,oqueue};
// task2 reads from *p and writes to *oqueue
t1.detach();
t2.detach();
}
|
这样当task1和task2析构时，会销毁它们的shared_ptr（在良好的设计中会隐式地调用），并且最后一个析构的任务会销毁sync_queue。
它很简单并高效。它并不包含需要复杂运行时系统的垃圾回收器。更重要的是，它不仅仅回收sync_queue关联的内存资源，它同时回收内置在sync_queue中管理两个任务线程同步的对象（互斥，锁，或其他）。我们这里做到的，仍然不仅仅是内存管理，而是通用资源管理。“隐藏的”同步对象也被处理了，和前面例子中处理文件句柄和流缓冲区一样。
在围绕任务的某些范围内，我们可以尝试引入一个唯一的拥有者，从而不使用shared_ptr；但是这样做通常不简单。因此C++11同时提供了unique_ptr（对唯一拥有关系）和shared_ptr（对共享拥有关系）。
4.3 类型安全
我刚刚只提到了和资源管理有关联的垃圾回收。它还在类型安全中扮演一个角色。只要我们有显式的delete操作，它就可能被错误使用。例如：
|
1
2
3
4
5
|
X* p =
new
X;
X* q = p;
delete
p;
// ...
q->do_something();
// the memory that held *p may have been re-used
|
不要这样做。裸露的delete非常危险——而且在常用的代码中是不必要的。把delete放到资源管理类的内部，例如string，ostream，thread，unique_ptr和shared_ptr。这样，delete就会和new正确对应，不会出错。
4.4 总结：资源管理理念
对于资源管理，我认为垃圾回收是最后的选择，而不是“解决方案”或者理念：
1. 运用适当的抽象，递归和显式地处理自己拥有的资源。限定对象的作用域会更好。
2. 当你需要使用指针/引用语义时，使用诸如unique_ptr和shared_ptr的“智能指针”，来表明拥有关系。
3. 如果其他都行不通（如，你的代码是一个程序的一部分，而程序中使用了大量不满足语言资源管理和错误处理策略的指针），尝试“手动”处理非内存资源，并内嵌一个保守的垃圾回收器，用它来处理那些几乎不可避免的内存泄露。
这个策略完美吗？不，但它是通用的，并且简单。传统的基于垃圾回收的策略也不完美，并且它们不能直接处理非内存资源。
附言
系列的第一篇在这里
- 误解1：“要理解C++，你必须先学习C”
- 误解2：“C++是一门面向对象的语言”
在下一篇中我将讲解
- 误解4：“为了效率，你必须编写底层代码”
- 误解5：“C++只适用于大型、复杂的程序”