按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
于是省去了函数调用的开销。这个过程与预处理有显著的不同，因为预处理器不能进行类型安全检查，或者进行自动类型转换。假如内联函数是成员函数，对象的地址（this）会被放在合适的地方，这也是预处理器办不到的。
C＋＋ 语言的函数内联机制既具备宏代码的效率，又增加了安全性，而且可以自由操作类的数据成员。所以在C＋＋ 程序中，应该用内联函数取代所有宏代码，〃断言assert〃恐怕是唯一的例外。assert是仅在Debug版本起作用的宏，它用于检查〃不应该〃发生的情况。为了不在程序的Debug版本和Release版本引起差别，assert不应该产生任何副作用。如果assert是函数，由于函数调用会引起内存、代码的变动，那么将导致Debug版本与Release版本存在差异。所以assert不是函数，而是宏。（参见6。5节〃使用断言〃）
8。5。2 内联函数的编程风格
关键字inline必须与函数定义体放在一起才能使函数成为内联，仅将inline放在函数声明前面不起任何作用。如下风格的函数Foo不能成为内联函数：
inline void Foo（int x； int y）； // inline仅与函数声明放在一起
void Foo（int x； int y）
｛
。。。
｝
而如下风格的函数Foo则成为内联函数：
void Foo（int x； int y）；
inline void Foo（int x； int y） // inline与函数定义体放在一起
｛
。。。
｝
所以说，inline是一种〃用于实现的关键字〃，而不是一种〃用于声明的关键字〃。一般地，用户可以阅读函数的声明，但是看不到函数的定义。尽管在大多数教科书中内联函数的声明、定义体前面都加了inline关键字，但我认为inline不应该出现在函数的声明中。这个细节虽然不会影响函数的功能，但是体现了高质量C＋＋/C程序设计风格的一个基本原则：声明与定义不可混为一谈，用户没有必要、也不应该知道函数是否需要内联。
定义在类声明之中的成员函数将自动地成为内联函数，例如
class A
｛
public：
void Foo（int x； int y） ｛ 。。。 ｝ // 自动地成为内联函数
｝
将成员函数的定义体放在类声明之中虽然能带来书写上的方便，但不是一种良好的编程风格，上例应该改成：
// 头文件
class A
｛
public：
void Foo（int x； int y）；
｝
// 定义文件
inline void A：：Foo（int x； int y）
｛
。。。
｝
8。5。3 慎用内联
内联能提高函数的执行效率，为什么不把所有的函数都定义成内联函数？
如果所有的函数都是内联函数，还用得着〃内联〃这个关键字吗？
内联是以代码膨胀（复制）为代价，仅仅省去了函数调用的开销，从而提高函数的执行效率。如果执行函数体内代码的时间，相比于函数调用的开销较大，那么效率的收获会很少。另一方面，每一处内联函数的调用都要复制代码，将使程序的总代码量增大，消耗更多的内存空间。以下情况不宜使用内联：
（1）如果函数体内的代码比较长，使用内联将导致内存消耗代价较高。
（2）如果函数体内出现循环，那么执行函数体内代码的时间要比函数调用的开销大。
类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造函数和析构函数可能会隐藏一些行为，如〃偷偷地〃执行了基类或成员对象的构造函数和析构函数。所以不要随便地将构造函数和析构函数的定义体放在类声明中。
一个好的编译器将会根据函数的定义体，自动地取消不值得的内联（这进一步说明了inline不应该出现在函数的声明中）。
8。6 一些心得体会
C＋＋ 语言中的重载、内联、缺省参数、隐式转换等机制展现了很多优点，但是这些优点的背后都隐藏着一些隐患。正如人们的饮食，少食和暴食都不可取，应当恰到好处。我们要辨证地看待C＋＋的新机制，应该恰如其分地使用它们。虽然这会使我们编程时多费一些心思，少了一些痛快，但这才是编程的艺术。
第9章 类的构造函数、析构函数与赋值函数
构造函数、析构函数与赋值函数是每个类最基本的函数。它们太普通以致让人容易麻痹大意，其实这些貌似简单的函数就象没有顶盖的下水道那样危险。
每个类只有一个析构函数和一个赋值函数，但可以有多个构造函数（包含一个拷贝构造函数，其它的称为普通构造函数）。对于任意一个类A，如果不想编写上述函数，C＋＋编译器将自动为A产生四个缺省的函数，如
A（void）； // 缺省的无参数构造函数
A（const A &a）； // 缺省的拷贝构造函数
~A（void）； // 缺省的析构函数
A & operate =（const A &a）； // 缺省的赋值函数
这不禁让人疑惑，既然能自动生成函数，为什么还要程序员编写？
原因如下：
（1）如果使用〃缺省的无参数构造函数〃和〃缺省的析构函数〃，等于放弃了自主〃初始化〃和〃清除〃的机会，C＋＋发明人Stroustrup的好心好意白费了。
（2）〃缺省的拷贝构造函数〃和〃缺省的赋值函数〃均采用〃位拷贝〃而非〃值拷贝〃的方式来实现，倘若类中含有指针变量，这两个函数注定将出错。
对于那些没有吃够苦头的C＋＋程序员，如果他说编写构造函数、析构函数与赋值函数很容易，可以不用动脑筋，表明他的认识还比较肤浅，水平有待于提高。
本章以类String的设计与实现为例，深入阐述被很多教科书忽视了的道理。String的结构如下：
class String
｛
public：
String（const char *str = NULL）； // 普通构造函数
String（const String &other）； // 拷贝构造函数
~ String（void）； // 析构函数
String & operate =（const String &other）； // 赋值函数
private：
char *m_data； // 用于保存字符串
｝；
9。1 构造函数与析构函数的起源
作为比C更先进的语言，C＋＋提供了更好的机制来增强程序的安全性。C＋＋编译器具有严格的类型安全检查功能，它几乎能找出程序中所有的语法问题，这的确帮了程序员的大忙。但是程序通过了编译检查并不表示错误已经不存在了，在〃错误〃的大家庭里，〃语法错误〃的地位只能算是小弟弟。级别高的错误通常隐藏得很深，就象狡猾的罪犯，想逮住他可不容易。
根据经验，不少难以察觉的程序错误是由于变量没有被正确初始化或清除造成的，而初始化和清除工作很容易被人遗忘。Stroustrup在设计C＋＋语言时充分考虑了这个问题并很好地予以解决：把对象的初始化工作放在构造函数中，把清除工作放在析构函数中。当对象被创建时，构造函数被自动执行。当对象消亡时，析构函数被自动执行。这下就不用担心忘了对象的初始化和清除工作。
构造函数与析构函数的名字不能随便起，必须让编译器认得出才可以被自动执行。Stroustrup的命名方法既简单又合理：让构造函数、析构函数与类同名，由于析构函数的目的与构造函数的相反，就加前缀'~'以示区别。
除了名字外，构造函数与析构函数的另一个特别之处是没有返回值类型，这与返回值类型为void的函数不同。构造函数与析构函数的使命非常明确，就象出生与死亡，光溜溜地来光溜溜地去。如果它们有返回值类型，那么编译器将不知所措。为了防止节外生枝，干脆规定没有返回值类型。（以上典故参考了文献＇Eekel； p55…p56＇）
9。2 构造函数的初始化表
构造函数有个特殊的初始化方式叫〃初始化表达式表〃（简称初始化表）。初始化表位于函数参数表之后，却在函数体 ｛｝ 之前。这说明该表里的初始化工作发生在函数体内的任何代码被执行之前。
构造函数初始化表的使用规则：
* 如果类存在继承关系，派生类必须在其初始化表里调用基类的构造函数。
例如
class A
｛。。。
A（int x）； // A的构造函数
｝；
class B ： public A
｛。。。
B（int x； int y）；// B的构造函数
｝；
B：：B（int x； int y）
： A（x） // 在初始化表里调用A的构造函数
｛
。。。
｝
* 类的const常量只能在初始化表里被初始化，因为它不能在函数体内用赋值的方式来初始化（参见5。4节）。
* 类的数据成员的初始化可以采用初始化表或函数体内赋值两种方式，这两种方式的效率不完全相同。
非内部数据类型的成员对象应当采用第一种方式初始化，以获取更高的效率。例如
class A
｛。。。
A（void）； // 无参数构造函数
A（const A &other）； // 拷贝构造函数
A & operate =（ const A &other）； // 赋值函数
｝；
class B
｛
public：
B（const A &a）； // B的构造函数
private：
A m_a； // 成员对象
｝；
示例9…2（a）中，类B的构造函数在其初始化表里调用了类A的拷贝构造函数，从而将成员对象m_a初始化。
示例9…2 （b）中，类B的构造函数在函数体内用赋值的方式将成员对象m_a初始化。我们看到的只是一条赋值语句，但实际上B的构造函数干了两件事：先暗地里创建m_a对象（调用了A的无参数构造函数），再调用类A的赋值函数，将参数a赋给m_a。
B：：B（const A &a）
： m_a（a）
｛
。。。
｝
B：：B（const A &a）
｛
m_a = a；
。。。
｝
示例9…2（a） 成员对象在初始化表中被初始化 示例9…2（b） 成员对象在函数体内被初始化
对于内部数据类型的数据成员而言，两种初始化方式的效率几乎没有区别，但后者的程序版式似乎更清晰些。若类F的声明如下：
class F
｛
public：
F（