effectIve c++ 学习笔记

记得前段时间又一次拿起《Effective C++》的时候，有种豁然开朗的感觉，所以翻出了我第一遍读时做的笔记。只做参考以及查阅之用。如有需要请参阅《Effective C++》书本。 by shenzi/2010.5.17
一.让自己习惯C++

条款01：视C++为一个语言联邦

为了更好的理解C++，我们将C++分解为四个主要次语言：

C。说到底C++仍是以C为基础。区块，语句，预处理器，内置数据类型，数组，指针统统来自C。

Object-Oreinted C++。这一部分是面向对象设计之古典守则在C++上的最直接实施。类，封装，继承，多态，virtual函数等等...

Template C++。这是C++泛型编程部分。

STL。STL是个template程序库。容器（containers），迭代器（iterators），算法（algorithms）以及函数对象（function objects）...

请记住：

这四个次语言，当你从某个次语言切换到另一个，导致高效编程守则要求你改变策略。C++高效编程守则视状况而变化，取决于你使用C++的哪一部分。

条款02：尽量以const，enum，inline替换#define

这个条款或许可以改为“宁可 以编译器替换预处理器”。即尽量少用预处理。

编译过程：.c文件－－预处理－－>.i文件－－编译-－>.o文件－-链接－－>bin文件
预处理过程扫描源代码，对其进行初步的转换，产生新的源代码提供给编译器。检查包含预处理指令的语句和宏定义，并对源代码进行相应的转换。预处理过程还会删除程序中的注释和多余的空白字符。可见预处理过程先于编译器对源代码进行处理。预处理指令是以#号开头的代码行。

例：#define ASPECT_RATIO 1.653
记号名称ASPECT_RATIO也许从未被编译器看见，也许在编译器开始处理源代码之前它就被预处理器移走了。即编译源代码时ASPECT_RATIO已被1.653取代。ASPECT_RATIO可能并未进入记号表（symbol table）。

替换：const double AspectRatio = 1.653；

好处应该有：多了类型检查，因为#define 只是单纯的替换，而这种替换在目标码中可能出现多份1.653；改用常量绝不会出现相同情况。

常量替换#define两点注意：

定义常量指针：

const char *authorName = “Shenzi”；

cosnt std::string authorName("Shenzi");

类专属常量：

static const int NumTurns = 5；//static 静态常量 所有的对象只有一份拷贝。

万一你编译器不允许“static整数型class常量”完成“in calss初值设定”（即在类的声明中设定静态整形的初值），我们可以通过枚举类型予以补偿：

enum { NumTurns = 5 }；

*取一个const的地址是合法的，但取一个enum的地址就不合法，而取一个#define的地址通常也不合法。如果你不想让别人获取一个pointer或reference指向你的某个整数常量，enum可以帮助你实现这个约束。

例：#define
CALL_WITH_MAX(a,b) f((a) > (b)) ? (a) : (b))

宏看起来像函数，但不会招致函数调用带来的额外开销，而是一种简单的替换。

替换：

template<typename T>

inline void callWithMax(cosnt T &a, cosnt T &b)

{

f(a > b ? a : b);

}

callWithMax是个真正的函数，它遵循作用于和访问规则。

请记住：

对于单纯常量，最好以const对象或enums替换#defines；

对于形似函数的宏，最好改用inline函数替换#defines。

条款03：尽可能使用const

const允许你告诉编译器和其他程序员某值应保持不变，只要“某值”确实是不该被改变的，那就该确实说出来。

关键字const多才多艺：

例：

char greeting[] = "Hello";

char *p = greeting; //指针p及所指的字符串都可改变；

const char *p = greeting; //指针p本身可以改变，如p = &Anyother；p所指的字符串不可改变；

char * cosnt p = greeting; //指针p不可改变，所指对象可改变；

const char * const
p = greeting; //指针p及所致对象都不可改变；

说明：

如果关键字const出现在星号左边，表示被指物事常量。const char *p和char const *p两种写法意义一样，都说明所致对象为常量；

如果关键字const出现在星号右边，表示指针自身是常量。

STL例子：

const std::vector<int>::interator iter = vec.begin();//作用像T *const, ++iter 错误：iter是const

std::vector<int>::const_iterator cIter = vec.begin();//作用像const T*，*cIter = 10 错误：*cIter是const

以下几点注意：

令函数返回一个常量值，往往可以降低因客户错误而造成的意外，而不至于放弃安全性和高效性。

例：const Rational operator* （const Rational &lhs, cosnt Rational &rhs）;

const成员函数使class接口比较容易被理解，它们使“操作const对象”称为可能；

说明：声明为const的成员函数，不可改变non-static成员变量，在成员变量声明之前添加mutable可让其在const成员函数中可被改变。

const_cast<char &>(static_cast<const TextBlock &>(*this))[position];

//static_cast
将TextBlock &转为const TextBlock &；

//const_cast将返回值去掉const约束；

请记住：

将某些东西声明为const可帮助编译器侦测出错误用法。const可被施加于任何作用域内的对象、函数参数、函数返回类型、成员函数本体；

编译器强制实施bitwise constness，但你编写程序时应该使用“概念上的车辆”（conceptual constness）；

当cosnt和non-const成员函数有着实质等价的实现时，令non-const版本调用const版本可避免代码重复。

条款04：确定对象被使用前已先被初始化

永远在使用对象之前先将它初始化。对于无任何成员的内置类型，你必须手工完成此事。至于内置类型以外的任何其它东西，初始化责任落在构造函数身上，确保每一个构造函数都将对象的每一个成员初始化。

赋值和初始化：

C++规定，对象的成员变量的初始化动作发生在进入构造函数本体之前。所以应将成员变量的初始化置于构造函数的初始化列表中。

ABEntry::ABEntry(const std::string& name, const std::string& address,

const std::list<PhoneNumber>& phones)

{

theName = name; //这些都是赋值，而非初始化

theAddress = address; //这些成员变量在进入函数体之前已调用默认构造函数，接着又调用赋值函数，

thePhones = phones; //即要经过两次的函数调用。

numTimesConsulted = 0;

}

ABEntry::ABEntry(const std::string& name, const std::string& address,

const std::list<PhoneNumber>& phones)

: theName(name), //这些才是初始化

theAddress(address), //这些成员变量只用相应的值进行拷贝构造函数，所以通常效率更高。

thePhones(phones),

numTimesConsulted(0)

{ }

所以，对于非内置类型变量的初始化应在初始化列表中完成，以提高效率。而对于内置类型对象，如numTimesConsulted（int），其初始化和赋值的成本相同，但为了一致性最好也通过成员初始化表来初始化。如果成员变量时const或reference，它们就一定需要初值，不能被赋值。

C++有着十分固定的“成员初始化次序”。基类总是在派生类之前被初始化，而类的成员变量总是以其说明次序被初始化。所以：当在成员初始化列表中列各成员时，最好总是以其声明次序为次序。

请记住：

为内置对象进行手工初始化，因为C++不保证初始化它们；

构造函数最好使用成员初始化列表，而不要在构造函数本体内使用赋值操作。初始化列表列出的成员变量，其排列次序应该和它们在类中的声明次序相同；

为免除“跨编译单元之初始化次序”问题，请以local static对象替换non-local static对象。

二.构造/析构/赋值运算

几乎你写的每个类都会有一或多个构造函数、一个析构函数、一个拷贝赋值操作符。如果这些函数犯错，会导致深远且令人不愉快的后果，遍及整个类。所以确保它们行为正确时生死攸关的大事。

条款05：了解C++默默编写并调用哪些函数

如果你自己美声明，编译器就会为类声明（编译器版本的）一个拷贝构造函数，一个拷贝赋值操作符和一个析构函数。此外如果你没有声明任何构造函数，编译器也会成为你声明一个默认构造函数。所有这些函数都是public且inline。

惟有当这些函数被需要（被调用），它们才会被编译器创建出来。即有需求，编译器才会创建它们。

默认构造函数和析构函数主要是给编译器一个地方用来放置“藏身幕后”的代码，像是调用基类和非静态成员变量的构造函数和析构函数(要不然它们该在哪里被调用呢？？)。

注意：编译器产生的析构函数是个non-virtual，除非这个类的基类自身声明有virtual析构函数。

至于拷贝构造函数和拷贝赋值操作符，编译器创建的版本只是单纯地将来源对象的每一个非静态成员变量拷贝到目标对象。

如一个类声明了一个构造函数（无论有没参数），编译器就不再为它创建默认构造函数。

编译器生成的拷贝赋值操作符：对于成员变量中有指针，引用，常量类型，我们都应考虑建立自己“合适”的拷贝赋值操作符。因为指向同块内存的指针是个潜在危险，引用不可改变，常量不可改变。

请记住：

编译器可以暗自为类创建默认构造函数、拷贝构造函数、拷贝赋值操作符，以及析构函数。

条款06：若不想使用编译器自动生成的函数，就该明确拒绝

通常如果你不希望类支持某一特定技能，只要不说明对应函数就是了。但这个策略对拷贝构造函数和拷贝赋值操作符却不起作用。因为编译器会“自作多情”的声明它们，并在需要的时候调用它们。

由于编译器产生的函数都是public类型，因此可以将拷贝构造函数或拷贝赋值操作符声明为private。通过这个小“伎俩”可以阻止人们在外部调用它，但是类中的成员函数和友元函数还是可以调用private函数。解决方法可能是在一个专门为了阻止拷贝动作而设计的基类。（Boost提供的那个类名为noncopyable）。

请记住：

为驳回编译器自动（暗自）提供的机能，可将相应的成员函数声明为private并且不予实现。使用像noncopyable这样的基类也是一种做法。

条款07：为多态基类声明virtual析构函数

当基类的指针指向派生类的对象的时候，当我们使用完，对其调用delete的时候，其结果将是未有定义——基类成分通常会被销毁，而派生类的充分可能还留在堆里。这可是形成资源泄漏、败坏之数据结构、在调试器上消费许多时间。

消除以上问题的做法很简单：给基类一个virtual析构函数。此后删除派生类对象就会如你想要的那般。

任何类只要带有virtual函数都几乎确定应该也有一个virtual析构函数。

如果一个类不含virtual函数，通常表示它并不意图被用做一个基类，当类不企图被当做基类的时候，令其析构函数为virtual往往是个馊主意。因为实现virtual函数，需要额外的开销（指向虚函数表的指针vptr）。

STL容器都不带virtual析构函数，所以最好别派生它们。

请记住：

带有多态性质的基类应该声明一个virtual析构函数。如果一个类带有任何virtual函数，它就应该拥有一个virtual析构函数。

一个类的设计目的不是作为基类使用，或不是为了具备多态性，就不该声明virtual析构函数。

条款08：别让异常逃离析构函数

C++并不禁止析构函数吐出异常，但它不鼓励你这样做。C++不喜欢析构函数吐出异常。

如果可能导致异常：

如果抛出异常，就结束程序。（强迫结束程序是个合理选项，毕竟它可以阻止异常从析构函数传播出去。）

捕获异常，但什么也不做。

如果某个操作可能在失败时抛出异常，而又存在某种需要必须处理该异常，那么这个异常必须来自析构函数以外的某个函数。

请记住：

析构函数绝对不要吐出异常。如果一个被析构函数调用的函数可能抛出异常，析构函数应该捕捉任何异常，然后吞下它们（不传播）或结束程序。

如果客户需要对某个操作函数运行期间抛出的异常做出反应，那么类应该提供一个普通函数（而非在析构函数中）执行该操作。

条款09：决不让构造和析构过程中调用virtual函数

你不该在构造函数和析构函数中调用virtual函数，因为这样的调用不会带来你预想的结果。

因为：基类的构造函数的执行要早于派生类的构造函数，当基类的构造函数执行时，派生类的成员变量尚未初始化。派生类的成员变量没初始化，即为指向虚函数表的指针vptr没被初始化又怎么去调用派生类的virtual函数呢？析构函数也相同，派生类先于基类被析构，又如何去找派生类相应的虚函数？

唯一好的做法是：确定你的构造函数和析构函数都没有调用虚函数，而它们调用的所有函数也不应该调用虚函数。

解决的方法可能是：既然你无法使用虚函数从基类向下调用，那么我们可以使派生类将必要的构造信息向上传递至基类构造函数。即在派生类的构造函数的成员初始化列表中显示调用相应基类构造函数，并传入所需传递信息。

请记住：

在构造和析构函数期间不要调用虚函数，因为这类调用从不下降至派生类。

条款10：令operator= 返回一个reference to *this

对于赋值操作符，我们常常要达到这种类似效果，即连续赋值：

int x, y, z;

x = y = z = 15;

为了实现“连锁赋值”，赋值操作符必须返回一个“引用”指向操作符的左侧实参。

即：

Widget & operator = (const Widget &rhs)

{

...

return *this;

}

所有内置类型和标准程序库提供的类型如string，vector，complex或即将提供的类型共同遵守。

请记住：

令赋值操作符返回一个reference to *this。

条款11：在operator =中处理“自我赋值”

先举几个自我赋值的例子：

例：Widget w；

w = w；

a[i] = a[j]; //i == j or i != j

*px = *py;// px,py指向同个地址；

以上情况都是对“值”的赋值，但我们涉及对“指针”和“引用”进行赋值操作的时候，才是我们真正要考虑的问题了。

看下面的例子：

Widget& Widget::operator=(const Widget& rhs)

{

delete pb; //这里对pb指向内存对象进行delete，试想 *this == rhs？情况会如何

pb = new Bitmap(*rhs.pb); //如果*this == rhs，那么这里还能new吗？“大事不妙”。

return *this;

}

也许以下代码能解决以上问题：

Widget& Widget::operator=(const Widget& rhs)

{

if (this == &rhs)

return *this; //解决了自我赋值的问题。

delete pb;

pb = new Bitmap(*rhs.pb);

return *this;

}
“许多时候一群精心安排的语句就可以导出异常安全（以及自我赋值安全）的代码。”，以上代码同样存在异常安全问题。

Widget& Widget::operator=(const Widget& rhs)

{

Bitmap *pOrig = pb; //记住原先的pb

pb = new Bitmap(*rhs.pb); //令pb指向*pb的一个复本

delete pOrig; //删除原先的pb

return *this; //这样既解决了自我赋值，又解决了异常安全问题。自我赋值，将pb所指对象换了个存储地址。

}

请记住：

确保当对象自我赋值时operator =有良好行为。其中技术包括比较“来源对象”和“目标对象”的地址、精心周到的语句顺序、以及copy-and-swap。

确定任何函数如果操作一个以上的对象，而其中多个对象是同一个对象时，其行为仍然正确。

条款12：复制对象时勿忘其每一个成员

还记得条款5中提到编译器在必要时会为我们提供拷贝构造函数和拷贝赋值函数，它们也许工作的不错，但有时候我们需要自己编写自己的拷贝构造函数和拷贝赋值函数。如果这样，我们应确保对“每一个”成员进行拷贝（复制）。

如果你在类中添加一个成员变量，你必须同时修改相应的copying函数（所有的构造函数，拷贝构造函数以及拷贝赋值操作符）。

在派生类的构造函数，拷贝构造函数和拷贝赋值操作符中应当显示调用基类相对应的函数，否则编译器可能又“自作聪明了”。

当你编写一个copying函数，请确保：

（1）复制所有local成员变量；

（2）调用所有基类内的适当copying函数。

但是，我们不该令拷贝赋值操作符调用拷贝构造函数，也不该令拷贝构造函数调用拷贝赋值操作符。想想，一个是拷贝(建立对象)，一个是赋值(对象已经存在)。

请记住：

Copying函数应该确保复制“对象内的所有成员变量”及“所有基类成员”；
不要尝试以某个copying函数实现另一个copying函数。应该将共同机能放进第三个函数中，并由两个copying函数共同调用。

三.资源管理

所谓资源就是，一旦用了它，将来必须还给系统。C++程序中最常使用的资源就好似动态分配内存（如果你new了，却忘了delete，会导致内存泄露），但内存只是你必须管理的众多资源之一。其它常见的有文件描述符（file descriptors）、互斥器（mutex）、图形界面中的字形和画刷。数据库连接以及网络sockets。当你不使用它们时，记得还给系统。

当你考虑到异常、函数内多重回传路径、程序维护员改动软件却没能充分理解随之而来的冲击，那么资源管理就显得复杂的多。

条款13：以对象管理资源

例：

void f()

{

Investment *pInv = createInvestment();

... //这里存在诸多“不定因素”，可能造成delete pInv；得不到执行，这可能就存在潜在的内存泄露。

delete pInv;

}

解决方法：把资源放进对象内，我们便可依赖C++的“析构函数自动调用机制”确保资源被释放。

许多资源被动态分配于堆内而后被用于单一区块或函数内。它们应该在控制流离开那个区块或函数时被释放。标准程序库提供的auto_ptr正是针对这种形势而设计的特制产品。auto_ptr是个“类指针对象”，也就是所谓的“智能指针”，其析构函数自动对其所指对象调用delete。

void f()

{

std::auto_ptr<Investment> pInv(createInvestment());

...

} //函数退出，auto_ptr调用析构函数自动调用delete，删除pInv；无需显示调用delete。

“以对象管理资源”的两个关键想法：

获得资源后立刻放进管理对象内（如auto_ptr）。每一笔资源都在获得的同时立刻被放进管理对象中。“资源取得时机便是初始化时机”（Resource Acquisition Is Initialization；RAII）。

管理对象运用析构函数确保资源被释放。即一旦对象被销毁，其析构函数被自动调用来释放资源。

由于auto_ptr被销毁时会自动删除它所指之物，所以不能让多个auto_ptr同时指向同一对象。所以auto_ptr若通过copying函数复制它们，它们会变成NULL，而复制所得的指针将取得资源的唯一拥有权！

看下面例子：

std::auto_ptr<Investment> pInv1(createInvestment()); //pInv1指向createInvestment()返回物；

std::auto_ptr<Investment> pInv2(pInv1);
//现在pInv2指向对象，而pInv1被设为NULL;

pInv1 = pInv2;
//现在pInv1指向对象，而pIn2被设为NULL;

受auto_ptr管理的资源必须绝对没有一个以上的auto_ptr同时指向它。即“有你没我，有我没你”。

auto_ptr的替代方案是“引用计数型智能指针”（reference-counting smart pointer；SCSP）、它可以持续跟踪共有多少对象指向某笔资源，并在无人指向它时自动删除该资源。

TR1的tr1::shared_ptr就是一个"引用计数型智能指针"。

void f()

{

...

std::tr1::shared_ptr<Investment> pInv1(createInvestment());
//pInv1指向createInvestment()返回物；

std::tr1::shared_ptr<Investment> pInv2(pInv1);
//pInv1，pInv2指向同一个对象；

pInv1 = pInv2;
//同上，无变化

...

} //函数退出，pInv1，pInv2被销毁，它们所指的对象也竟被自动释放。

auto_ptr和tr1::shared_ptr都在其析构函数内做delete而不是delete[]，也就意味着在动态分配而得的数组身上使用auto_ptr或tr1::shared_ptr是个潜在危险，资源得不到释放。也许boost::scoped_array和boost::shared_array能提供帮助。还有，vector和string几乎总是可以取代动态分配而得的数组。

请记住：

为防止资源泄漏，请使用RAII对象，它们在构造函数中获得资源并在析构函数中释放资源。

两个常被使用的RAII类分别是auto_ptr和tr1::shared_ptr。后者通常是较佳选择，因为其拷贝行为比较直观。若选择auto_ptr，复制动作会使他（被复制物）指向NULL。

条款14：在资源管理类中小心拷贝行为

我们在条款13中讨论的资源表现在堆上申请的资源，而有些资源并不适合被auto_ptr和tr1::shared_ptr所管理。可能我们需要建立自己的资源管理类。

例：

void lock(Mutex *pm); //锁定pm所指的互斥量

unlock(Mutex *pm); //将pm解除锁定

我们建立的资源管理类可能会是这样：

class Lock

{

public:

explicit Lock(Mutex *pm)

: mutexPtr(pm)

{

lock(mutexPtr);

}

~Lock()

{

unlock(mutexPtr);

}

private:

Mutex *mutexPtr;

};

但是，如果Lock对象被复制，会发生什么事？？？

“当一个RAII对象被复制，会发生什么事？”大多数时候你会选择一下两种可能：

禁止复制。如果复制动作对RAII类并不合理，你便应该禁止之。禁止类的copying函数参见条款6。

对底层资源使用”引用计数法“。有时候我们又希望保有资源，直到它的最后一个使用者被销毁。这种情况下复制RAII对象时，应该将资源的”被引用计数“递增。tr1::shared_ptr便是如此。

通常只要内含一个tr1::shared_ptr成员变量，RAII类便可实现”引用计数“行为。

class Lock

{

public:

explicit Lock(Mutex *pm)

: mutexPtr(pm,
unlock) //由于tr1::shared_ptr缺省行为是”当引用计数为0时删除其所指物“，幸运的是 //我们可以指定”引用计数“为9时被调用的所谓”删除器“，即第二个参数unlock

{

lock(mutexPtr.get());

}

private:

std::tr1::shared_ptr<Mutex> mutexPtr;

};

本例中，并没说明析构函数，因为没有必要。编译器为我们生成的析构函数会自动调用其non-static成员变量（mutexPtr）的析构函数。而mutexPtr的析构函数会在互斥量”引用计数“为0时自动调用tr1::shared_ptr的删除器（unlock）。

Copying函有可能被编译器自动创建出来，因此除非编译器所生成版本做了你想要做的事，否则你得自己编写它们。

请记住：

复制RAII对象必须一并复制它所管理的资源，所以资源的copying行为决定RAII对象的copying行为。

普遍而常见的RAII类拷贝行为是：抑制拷贝，施行引用计数法。不过其它行为也可能被实现。

条款15：在资源管理类中提供对原始资源的访问

前几个条款提到的资源管理类很棒。它们是你对抗资源泄漏的堡垒。但这个世界并不完美，许多APIs直接指涉资源，这时候我们需要直接访问原始资源。

这时候需要一个函数可将RAII对象（如tr1::shared_ptr）转换为其所内含之原始资源。有两种做法可以达成目标：显示转换和隐式转换。

tr1::shared_ptr和auto_ptr都提供一个get成员函数，用来执行显示转换，也就是返回智能指针内部的原始指针（的复件）。就像所有智能指针一样， tr1::shared_ptr和auto_ptr也重载了指针取值操作符（operator->和operator*），它们允许隐式转换至底部原始指针。（即在对智能指针对象实施->和*操作时，实际被转换为被封装的资源的指针。）

class Font

{

public:

...

FontHandle get() const //FontHandle 是资源；
显示转换函数

{

return f;

}

operator FontHandle() const //隐式转换
这个值得注意，可能引起“非故意之类型转换”

{

return f;

}

...

};

是否该提供一个显示转换函数（例如get成员函数）将RAII类转换为其底部资源，或是应该提供隐式转换，答案主要取决于RAII类被设计执行的特定工作，以及它被使用的情况。

显示转换可能是比较受欢迎的路子，但是需要不停的get，get；而隐式转换又可能引起“非故意之类型转换”。

请记住：

APIs往往要求访问原始资源，所以每一个RAII类应该提供一个“取得其所管理之资源”的方法。

对原始资源的访问可能经由显示转换或隐式转换。一般而言显示转换比较安全，但隐式转换对客户比较方便。

条款16：成对使用new和delete时要采取相同形式

先看下一下代码：

std::string *stringArray = new std::string[100];

...

delete stringArray;

使用了new动态申请了资源，也调用了delete释放了资源。但这代码存在“不明确行为”。stringArray对象中的99个不太可能被适当删除，因为它们的析构函数很可能没被调用。

当我们使用new，有两件事情发生：第一，内存被分配出来；第二，针对此内存会有一个（或更多）构造函数被调用。当你使用delete，也有两件事发生：针对此内存会有一个（或多个）析构函数被调用，然后内存才被释放。delete的最大问题在于：即将被删除的内存之内究竟有多少对象？这个问题的答案决定了有多少个析构函数必须被调用起来。

解决以上问题事实上很简单：如果你调用new时使用[]，你必须在对应调用delete时也使用[]。如果你调用new时没有使用[]，那么也不该在对应调用delete时使用[]。

最好尽量不要对数组形式作typedefs动作。因为这样容易引起delete操作的“疑惑”（需不需要[]呢？？？）。

请记住：

如果你在new表达式中使用[]，必须在相应的delete表达式中也使用[]。如果你在new表达式中不使用[]，一定不要在相应的delete表达式中使用[]。

条款17：以独立语句将newed对象置入智能指针

为了避免资源泄漏的危险，最好在单独语句内以智能指针存储newed所得对象。

即：

int priority();

void processWidget(std::tr1::shared_ptr<Widget> pw, int priority);

std::tr1::shared_ptr<Widget> pw(new Widget); //即在传入函数之前对智能指针初始化，而不是在传入参数中 //对其初始化，因为那样可能引起操作序列的问题。

processWidget(pw, priority());

请记住：

以独立语句将newed对象存储于（置入）智能指针内。如果不这样做，一旦异常抛出，有可能导致难以察觉的资源泄漏。

四.设计与声明

所谓软件设计，是“令软件做出你希望它做的事情”的步骤和做法，通常以颇为一般性的构想开始，最终变成十足的细节，以允许特殊接口的开发。

条款18：让接口容易被正确使用，不易被误用

理想上，如果客户企图使用某个接口而却没有获得他所预期的行为，这个代码不该通过编译；如果代码通过了编译，它的作为就该是客户所想要的。

欲开发一个“容易被正确使用，不容易被误用”的接口，首先必须考虑客户可能做出什么样的错误。

许多客户端错误可以因为导入新类型而获得预防。在防范“不值得拥有的代码”上，类型系统是你的主要同盟国。

struct Day

{

explicit Day(int d) //explicit 避免隐式的转换。

:val(d) {}

int val;

};

对日期进行类似的类型封装，能有效地避免不恰当的日期赋值。

“除非有好的理由，否则应该尽量令你的类型（定义的类）的行为与内置类型一致”。

在资源管理方面，也许我们应该“先发制人”，即让函数返回一个资源的指针改为返回一个只能指针。

例如：

std::tr1::shared_ptr<Investment> createInvestment();

这便实质上强迫客户将返回值存储于一个tr1::shared_ptr内，几乎消除了忘记删除底部Investment对象的可能性。

tr1::shared_ptr提供的某个构造函数接受两个实参：一个是被管理的指针，另一个是引用次数变成0时被调用的“删除器”。但我们自己制定第二个参数，当然这是安全的。但是留给客户，那也许存在危险。

std::tr1::shared_ptr<Investment> //tr1::shared_ptr构造函数坚持第一个参数必须是个指针。

pInv(static_cast<Investment*>(0), getRidOfInvestment);

tr1::shared_ptr有一个特别好的性质是：它会自动使用它的“每个指针专属的删除器”，因而消除另一个潜在的客户错误：所谓的“cross-DLL problem”。因为它缺省的删除器是来自“tr1::shared_ptr诞生所在的那个DLL”的delete。

请记住：

好的接口很容易被正确使用，不容易被误用。你应该在你的所有接口中努力达成这些性质。
“促进正确使用”的办法包括接口的一致性，以及与内置类型的行为兼容。
“阻止误用”的办法包括建立新类型、限制类型上的操作，束缚对象值，以及消除客户的资源管理责任。

tr1::shared_ptr支持定制删除器。这可防范DLL问题，可被用来自动解除互斥量等等。

条款19：设计class犹如设计type

C++就像在其它面向对象编程语言一样，当你定义一个新class，也就定义了一个新type。这意味着你并不只是类的设计者，更是类型的设计者。重载函数和操作符、控制内存的分配和归还、定义对象的初始化和终结......全部在你手上。

设计优秀的类是一项艰巨的工作，因为涉及好的类型是一项艰巨的工作。好的类型有自然的语法，直观的语义，以及一或多个高效实现品。

设计一个良好的类，或者称作类型，考虑一下设计规范：

新类型的对象应该如何被创建和销毁？
对象的初始化和对象的赋值该有什么样的差别？
新类型的对象如果被passed by value（值传递），意味着什么？
什么是新类型的“合法值”？
你的新类型需要配合某个继承图系吗？
你的新类型需要什么样的转换？
什么样的操作符和函数对此新类型而言是合理的？
什么样的标准函数应该驳回？
谁该取用新类型的成员？
什么是新类型的“未声明接口”？
你的新类型有多少一般化？
你真的需要一个新类型吗？

请记住：

Class的设计就是type的设计。在定义一个新的type之前，请确定你已经考虑过本条款覆盖的所有讨论主题。

条款20：宁以pass-by-reference-to-const替代psss-by-value

缺省情况下C++以by value方式传递对象至函数。除非你另外指定，否则函数参数都是以实际实参的副本为初值，而调用端所获得的亦是返回值的一个副本。这些副本由对象的拷贝构造函数产生。

所以在以对象为by value时，可能会调用相应的构造函数（成员对象的构造、基类对象的构造），然后调用对应的析构函数。所以以by value的形式开销还是比较大的。

如果我们用pass-by-reference-to-const，例如：

bool validateStudent(const Student& s);
//const，希望别对传入对象进行不恰当的修改；

这种传递方式效率高得多：没有任何构造函数或析构函数被调用，因为没有任何新对象被创建。

以传引用方式传递参数也可以避免对象切割问题：即当一个派生类对象以传值的方式传递并被视为一个基类对象，基类对象的拷贝构造函数会被调用，而“造成此对象的行为像个派生类对象”的那些特化性质全被切割掉了，仅仅留下了基类对象。这一般不是你想要的。

所以我们一般的做法应该是这样：内置对象和STL的迭代器和函数对象，我们一般以传值的方式传递，而其它的任何东西都以传引用的方式传递。

请记住：

尽量以pass-by-reference-to-const替代pass-by-value。前者通常比较高效，并可避免切割问题。

以上规则并不使用于内置类型，以及STL的迭代器和函数对象。对它们而言，pass-by-value往往比较适当。

条款21：必须返回对象时，别妄想返回其reference

当我们领悟条款20中传值的开销后，总是避免于少用传值，然而在返回对象时，要格外小心了，因为你可能：传递一些引用或指针指向其实已经不存在的对象。这可不是件好事。

任何时候看到一个reference声明式，你都应该立刻问自己，它的另一个名称是什么？

函数创建新对象的途径有二：在栈空间和堆空间

栈上：即在函数内的局部变量。局部变量在函数返回后就没有存在的意义，若还对它“念念不忘”，将带来灾难性后果。所以传引用在栈上不可行。

堆上：在堆上构造一个对象，并返回。看似可行，也埋下了资源泄漏的危险。谁该对这对象实施delete呢？别把这种对资源的管理寄托完全寄托于用户。所以传引用在堆上不可行。

可能还有一种想法：把“让返回的引用指向一个被定义于函数内部的静态对象”。出于我们对多线程安全性的疑虑，以及当线程中两个函数对单份对象的处理也可能带来不可测行为。所以静态对象也是不可行的。

一个“必须返回新对象”的函数的正确写法是：就让那个函数返回一个新对象。

编译器实现者实行最优化，用以改善产出码的效率却不改变其观察的行为。所以我们还是老老实实的返回一个对象吧。

请记住：

绝不要返回pointer或reference指向一个local stack对象，或返回reference指向一个heap-allocated对象，或返回pointer或reference指向一个local static对象而有可能同时需要多个这样的对象。

条款22：将成员变量声明为private

将成员变量隐藏在函数接口的背后，可以为“所有可能的实现”提供弹性。例如,这可使得成员变量被读或写时轻松通知其它对象、可以验证calss的约束条件以及函数的前提和事后状态、可以在多线程环境中执行同步控制......

不封装意味不可改变！成员变量的封装性与“成员变量的内容改变时所坏量的代码数量”成反比。

请记住：

切记将成员变量声明为private。这可赋予客户访问数据的一致性、可细微划分访问控制、允许约束条件获得保护，并提供class作者以充分的实现弹性。

protected并不比public更具封装性。

条款23：宁以non-member、non-friend替换member函数

一般我们相当然以为类中的成员函数更具封装性，而实际上并不是那么一回事，因为成员函数不仅可以访问private成员变量，也可以取用private函数、enums、typedefs等等。而非成员非友元函数能实现更大的封装性，因为它只能访问public函数。

将所有便利函数放在多个头文件内但隶属同一个命名空间，意味客户可以轻松扩展这一组便利函数。需要做的就是添加更多non-member non-friend函数到此命名空间内。

请记住：

宁可拿non-member non-friend函数替代member函数。这样做可以增加封装性、包裹弹性和机能扩充性。

条款24：若所有参数皆需类型转换，请为此采用non-member函数

通常，令类支持隐式类型转换通常是个糟糕的主意。当然这条规则有其例外，最常见的例外是在建立数值类型时。

例：

const Rational operator*(const Rational& rhs) const;

如果定义一个有理数类，并实现*操作符为成员函数，如上所示；那么考虑一下调用：

Rational oneHalf(1, 2);

result = oneHalf * 2; // 正确，2被隐式转换为Rational（2，1）

//编译器眼中应该是这样：const Rational temp(2); result = oneHalf * temp;

result = 2 * oneHalf; // 错误，2，可不被认为是Rational对象；因此无法调用operator*

可见，这样并不准确，因为乘法（*）应该满足交换律，不是吗？

所以，支持混合式算术运算的可行之道应该是：让operator*成为一个non-member函数，允许编译器在每一个实参上执行隐式类型转换：

class Rational

{

... // contains no operator*

};

const Rational operator*(const Rational& lhs, Rational& rhs)

{

return Rational(lhs.numerator() * rhs.numerator(),

lhs.denominator() * rhs.denominator());

}

Rational oneFourth(1, 4);

Rational result;

result = oneFourth * 2;

result = 2 * oneFourth; //这下两个都工作的很好，通过隐式转换实现

成员函数的方面是非成员函数，而不是友元函数。

可以用类中的public接口实现的函数，最好就是非成员函数，而不是采用友元函数。

请记住：

如果你需要为某个函数的所有参数（包括被this指针所指的那个隐喻参数）进行类型转换，那么这个函数必须是个non-member。

条款25：考虑写出一个不抛异常的swap函数

......

请记住：

当std::swap对你的类型效率不高时，提供一个swap成员函数，并确定这个函数不抛出异常。

如果你提供一个member swap，也该提供一个non-member swap用来调用前者。对于class（而非templates），也请特化std::swap。

调用swap时应针对std::swap使用using声明式，然后调用swap并且不带任何“命名空间资格修饰”。

为“用户定义类型”进行std templates全特化是好的，但千万不要尝试在std内加入某些对std而言全新的东西。

五.实现

大多数情况下，适当提出拟的类定义以及函数声明，是花费最多心力的两件事。尽管如此，还是有很多东西需要小心：太快定义变量可能造成效率上的拖延；过度使用转型（casts）可能导致代码变慢又难维护，又招来微妙难解的错误；返回对象“内部数据之号码牌（handls）”可能会破坏封装并留给客户虚吊号码牌；为考虑异常带来的冲击则可能导致资源泄漏和数据败坏；过度热心地inlining可能引起代码膨胀；过度耦合则可能导致让人不满意的冗长建置时间。

条款26：尽可能延后变量定义式的出现时间

只要你定义了一个变量而其类型带有一个构造函数或析构函数，那么当程序的控制流到达这个变量定义式时，你便得承受构造成本；当这个变量离开其作用域时，你便得承受析构成本。即使这个变量最终并为被使用，仍需耗费这些成本，所以应该尽量避免这种情形。

std::string encryptPassword(const std::string& password)

{

using namespace std;

string encrypted1;

if (password.length() < MinimumPasswordLength)

{

throw logic_error("Password is too short"); //注意：可能抛出异常

}

string encrypted2;

...

return encrypted;

}

如上代码，encrypted在2处定义是个不错的选择，因为如果抛出异常，那么encrypted的构造和析构可是做了无用功啊！

还有一点要注意：“通过默认构造函数构造出一个对象然后对它赋值”比“直接在构造函数时制定初值”效率差。

“尽可能延后”的真正意义应该是：你不只应该延后变量的定义，直到非得使用该变量的前一刻为止，甚至应该尝试延后这份定义直到能够给它初值实参为止。

//方法A:定义循环外

Widget w;

for (int i = 0; i < n; ++i)

{

w = some value dependent on i;

...

} //1个构造函数+1个析构函数+n个赋值操作；

//方法B：定义循环外

for (int i = 0; i < n; ++i)

{

Widget w(some value dependent on i);

...

} //n个构造函数+n个析构函数

除非：1.你知道赋值成本比“构造+析构”成本低；2.你正在处理代码中效率高度敏感的部分，否则应该使用方法B。

请记住：

尽可能延后变量定义式的出现。这样做可增加程序的清晰度并改善程序效率。

条款27：尽量少做转型动作

C++规则的设计目标之一是，保证“类型错误”绝不可能发生。不幸的是，转型（casts）破坏了类型系统。那可能导致任何种类的麻烦，有些容易辨识，有些非常隐晦。

C风格的转型动作看起来像这样：

(T)expression //将expression转型为T

函数风格的转型动作看起来像这样：

T(expression) //将expression转型为T

C++还提供四种新式转型：

const_cast:通常被用来将对象的常量性转除；即去掉const。

dynamic_cast:主要用来执行“安全向下转型”，也就是用来决定某对象是否归属继承体系中的某个类型。

reinterpret_cast:意图执行低级转型，实际动作可能取决于编译器，这也就表示它不可移植。

static_cast:用来强迫隐式转换，例如将non-const转型为const，int转型为double等等。

尽量使用新式转型：

它们很容易在代码中被辨识出来，因而得以简化“找出类型系统在哪个地点被破坏”的过程。

各转型动作的目标愈窄化，编译器愈可能诊断出错误的运用。

请记住：

如果可以，尽量避免转型，特别是在注重效率的代码中避免dynamic_casts。如果有个设计需要转型动作，试着发展无需转型的替代设计。

如果转型是必要的，试着将它隐藏于某个函数背后。客户随后可以调用该函数，而不需将转型放进他们自己的代码内。

宁可使用C++-style（新式）转型，不要使用旧式转型。前者很容易辨识出来，而且也比较有着分门别类的执掌。

条款28：避免返回handls指向对象内部成分

struct RectData

{

Point ulhc;

Point lrhc;

};

class Rectangle

{

public:

...

Point& upperLeft()
const { return pData->ulhc; }1//const只对函数内进行保护，函数返回后呢？？

Point& lowerRight()
const { return pData->lrhc; }2
//const只对函数内进行保护，函数返回后呢？？

private:

std::tr1::shared_ptr<RectData> pData;

...

};

1，2两函数都返回引用，指向private内部数据，调用者于是可通过这些引用更改内部数据！这严重破坏了数据的封装性，对私有成员进行直接操作？太不可思意了！

const Point& upperLeft() const { return pData->ulhc; }3

const Point&
lowerRight() const { return pData->lrhc; }4

或者将1，2改为3，4，这就限制了客户的“涂改权”，只有“读取权”。

但终究“返回一个handle代表对象内部成分”总是危险的。特别是将返回的指针或引用赋值给其它指针或引用，那么久造成了“悬空”。

请记住：

避免返回handles（包括reference、指针、迭代器）指向对象内部。遵守这个条款可增加封装性，帮助const成员函数的行为像个const，并将发生“虚吊号码牌”（dangling handles）的可能性降至最低。

条款29：为“异常安全”而努力是值得的

请记住：

异常安全函数（Exception-safe functions）即使发生异常也不会泄漏资源或允许任何数据结构败坏。这样的函数区分为三种可能的保证：基本型、强烈型、不抛异常型。

“强烈保证”往往能够以copy-and-swap实现出来，但“强烈保证”并非对所有函数都可实现或具备现实意义。

函数提供的“异常安全保证”通常最高只等于其所调用之各个函数的“异常安全保证”中的最弱者。

条款30：透彻了解inlining的里里外外

Inline函数，多棒的点子！它们看起来像函数，动作像函数，比宏好得多，可以调用它们又不需蒙受函数调用所招致的额外开销。你实际获得的比想象的还多，编译器有能力对执行语境相关最优化。然而编写程序就像现实生活一样，没有白吃的午餐。inline函数也不例外，这样做可能增加你的目标码。

如果inline函数的本体很小，编译器针对“函数本体”所产生的码可能比针对“函数调用”所产出的码更小。果真如此，将函数inlining确实可能导致较小的目标码和较高的指令高速缓存装置击中率。

记住，inline只是对编译器的一个申请，不是强制命令。这项申请可以隐喻提出，也可以明确提出。隐喻方式是将函数定义于class定义式内,这样的函数通常是成员函数，friend函数也可被定义于class内，如果真是那样，它们也是被隐喻声明为inline。明确声明inline函数的做法则是在其定义式钱加上关键字inline。

Inline函数通常一定被置于头文件内，因为大多数建置环境在编译过程中进行inlining，而为了将一个“函数调用”替换为“被调用函数的本体”，编译器必须知道那个函数长什么样子。

Template通常也被置于头文件内，因为它一旦被使用，编译器为了将它具现化，需要知道哦啊它长什么样子。

Template的具现化与inlining无关。如果你正在写一个template而你认为所有根据此template具现出来的函数都应该inlined，请将此template声明为inline；但如果你写的template煤油理由要求它所具现的每一个函数都是inlined，就应该避免将这个template声明为inline。

一个表面上看似inline的函数是否真实inline，取决于你的建置环境，主要取决于编译器。

有的时候虽然编译器有意愿inlining某个函数，还是可能为该函数生成一个函数本体（函数指针，构造函数，析构函数）。

对程序开发而言，将上述所有考虑牢记在新很是重要，但若从纯粹实用观点出发，有一个事实比其它因素更重要：大部分调试器面对inline函数都束手无策。

这使我们在决定哪些函数该被声明为inline而哪些函数不该时，掌握一个合乎逻辑的策略。一开始先不要将任何函数声明为inline，或至少将inlining施行范围局限在那些“一定成为inline”或“十分平淡无奇”的函数身上。

请记住：

将大多数inlining限制在小型、被频繁调用的函数身上。这可使日后的调试过程和二进制升级更容易，也可使潜在的代码膨胀问题最小化，是程序的速度提升机会最大化。

不要只因为function templates出现在头文件，就将它们声明为inline。

条款31：将文件间的编译依存关系降至最低

请记住：

支持“编译依存性最小化”的一般构想是：相依于声明式，不要相依于定义式。基于此构想的两个手段是Handle classed和Interface classes。

程序库头文件应该以“完全且仅有声明式”（full and declaration-only forms）的形式存在。这种做法不论是否涉及templates都适用。

六.继承与面向对象设计

如果你了解C++各种特性的意义，你会发现，你对OOP的看法改变了。它不再是一项用来划分语言特性的仪典，而是可以让你通过它说出你对软件系统的想法。一旦你知道该通过它说些什么，移转至C++世界也就不再是可怕的高要求了。

条款32：确定你的public继承塑模出is-a关系

以C++进行面向对象编程，最重要的一个规则是：public inheritance（公有继承）意味is-a（是一种）的关系。

如果你令class D以public形式继承class B，你便是告诉C++编译器（以及你的代码读者）说，每一个类型为D的对象同时也是一个类型为B的对象，反之不成立。你的意思是B比D表现出更一般化得概念，而D比B表现出更特殊化的概念。你主张：“B对象可派上用场的任何地方，D对象一样可以派上用场”，因为每一个D对象都是一种（是一个）B对象。反之如果你需要一个D对象，B对象无法效劳，因为虽然每个D对象都是一个B对象，反之并不成立。

在C++领域中，任何函数如果期望获得一个类型为基类的实参（而不管是传指针或是引用），都也愿意接受一个派生类对象（而不管是传指针或是引用）。（只对public继承才成立。）

好的接口可以防止无效的代码通过编译，因此你应该宁可采取“在编译期拒绝”的设计，而不是“运行期才侦测”的设计。

请记住：

“public继承”意味is-a。适用于base classes身上的每一件事情一定也使用于derived classes身上，因为每一个derived classes对象也都是一个base classes对象。

条款33：避免遮掩继承而来的名称

C++的名称遮掩规则所做的唯一事情就是：遮掩名称。至于名称是否是相同或不同的类型，并不重要。即，只要名称相同就覆盖基类相应的成员，不管是类型，参数个数，都无关紧要。派生类的作用域嵌套在基类的作用域内。

C++的继承关系的遮掩名称也并不管成员函数是纯虚函数，非纯虚函数或非虚函数等。只和名称有关。

如果你真的需要用到基类的被名称遮掩的函数，可以使用using声明式，引入基类的成员函数。

请记住：

derived calsses内的名称会遮掩base classes内的名称。在public继承下从来没有人希望如此。

为了让被遮掩的名称再见天日，可使用using声明式或转交函数（forwarding function）。

条款34：区分接口继承和实现继承

表面上直截了当的public继承概念，经过更严密的检查之后，发现它由两部分组成：函数接口继承和函数实现继承。

成员函数的接口总是会被继承。
声明一个纯虚函数的目的是为了让派生类只继承函数接口。

声明一个虚函数的目的是让派生类继承该函数的接口和缺省实现。

声明一个非虚函数的目的是为了令派生类继承函数的接口及一份强制性实现。

请记住：

接口继承和实现继承不同。在public继承之下，derived classes总是继承base class的接口。

pure virtual函数只具体制定接口继承。
简朴的（非纯）impure virtual函数具体制定接口继承及缺省实现继承。
non-virtual函数具体制定接口继承以及强制性实现继承。

条款35：考虑virtual函数以外的其它选择

请记住：



virtual函数的替代方案包括NVI手法及Strategy设计模式的多种形式。NVI手法自身是一个特殊形式的Template Method设计模式。

将机能从成员函数移到class外部函数，带来的一个缺点是，非成员函数无法访问class的non-public成员。

tr1::function对象的行为就像一般函数指针。这样的对象可接纳“与给定之目标签名式（target signature）兼容”的所有可调用物（callable entities）。

条款36：绝不重新定义继承而来的non-virtual函数

请记住：

绝对不要重新定义继承而来的non-virtual函数。

条款37：绝不重新定义继承而来的缺省参数值

对于non-virtual函数，上一条款说到，“绝不重新定义继承而来的non-virtual函数”，而对于继承一个带有缺省参数值的virtual函数，也是如此。即绝不重新定义继承而来的缺省参数值。因为：virtual函数系动态绑定（dynamically
bound），而缺省参数值确实静态绑定（statically bound）。意思是你可能会在“调用一个定义于派生类内的虚函数”的同时，却使用基类为它所指定的缺省参数值。

请记住：

绝对不要重新定义一个继承而来的缺省参数值，因为缺省参数值都是静态绑定，而virtual函数——你唯一应该覆写的东西——却是动态绑定。

条款38：通过符合塑模出has-a或“根据某物实现出”

请记住：

复合（composition）的意义和public继承完全不同。
在应用域（application domain），复合意味has-a（有一个）。在实现域（implementation domain），复合意味is-implemented-in-terms-of（根据某物实现出）。