在C++编程中应该尽量使用const和inline来代替#define，尽量做到能不用#define就不用。#define常见的用途有“定义常量”以及“定义宏”，但其中存在诸多的弊病。

　　第一，查错不直观，不利于调试。Define的定义是由预处理程序处理的，作的是完全的文本替换，不做任何的类型检查。在编译器处理阶段，define定义的东西已经被完全替换了，这样在debug的时候就看不到任何的相关信息，即跟踪时不能step into宏。例如，把ASPECT_RATIO用define定义成1.653，编译器就看不到ASPECT_RATIO这个名字了。如果编译器报1.653错，那么就无从知道此1.653来自于何处。在真正编码的时候应该使用如下的语句来定义：


static const double ASPECT_RATIO = 1.653;

　　// in header file def.h
　　#define Apple 1
　　#define Orange 2
　　　 #define Pineapple 3
　　 …
　　// in some cpp file that includes the def.h
　　enum Colors {White, Black, Purple, Orange};

　　int a = 5, b = 0;
　　max(++ a, b);
　　max(++ a, b + 10);

　　template<class T>
　　inline const T&
　　max(const T& a, const T& b) { return a > b ? a : b; }

　　// prefix form: increment and fetch
　　UPInt& UPInt::operator++()
　　　{
　　　 *this += 1; // increment
　　　return *this; // fetch
　　　}
　　// postfix form: fetch and increment
　　　const UPInt UPInt::operator++(int)
　　　{
　　　 UPInt oldValue = *this; // fetch
　　　++(*this); // increment
　　　 return oldValue; // return what was fetched
　　 }

　　一般情况下不需要区分是先++，还是后++，但是我们在编写程序的时候最好能习惯性的将其写成++i的形式，如在使用STL中的iterator时，prefix与postfix会有相当大的性能差异。请不要小看这些细节，实际在编写程序的时候，若不注意具体细节，你会发现程序的性能会非常的低。但要注意，虽然在大多数情况下可以用prefix来代替postfix，但有一种情况例外，那就是有[]操作符时，比如gzArray [++index] 是不等于 gzArray[index++]的。

4、Minimizing Compile-time Dependencies

　　有些人在编写程序时，往往喜欢将一个.h文件包含到另一个.h文件，而实践证明在做大型软件时这是一个非常不好的习惯，因这样会造成很多依赖的问题，包含较多的.h文件，别人又使用了这个class，而在他的那个工程中可能并不存在这些.h文件，这样很可能就编译不能通过。而且这样做，还可能造成很难去更新一个模块的情况。因为一个.h文件被很多模块包含的话，如果修改了此.h文件，在编译系统的时候，编译器会去寻找哪些模块依赖于某个被修改过的.h文件，那么就导致了所有包含入此.h文件的模块全都要进行重新编译。在项目比较小的时候，大家可能还感觉不到差别，但是如果说是在大型的软件系统里，你可能编译一遍源码需要七、八个小时。如果你这个.h文件被很多模块包含的话，就算在.h文件中加了一行注释，在编译时编译器检查哪些文件被改动，那么所有包含入此.h文件的模块都会被重新编译，造成巨大的时间和精力负担。对于此问题，解决的方法就是让.h文件自包含，也就是说让它包含尽量少的东西。所谓尽量少是指如删掉任何一个它包含进来的.h文件，都将无法正常进行工作。其实在很多情况下，并不需要一个.h文件去包含另一个.h文件，完全可以通过class声明来解决依赖关系的这种问题。再来看下面这个例子：1Z0-043

　　#include "a.h" // class A
　　#include "b.h" // class B
　　#include "c.h" // class C
　　#include "d.h" // class D
　　#include "e.h" // class E
　　class X : public A, private B
　　{
　　　public:
　　E SomeFunctionCall(E someParameter);
　　　private:
　　 D m_dInstance;
　　};

　　当类X从类A和类B中派生时，需要知道X在内存中都有哪些data，通常在内存中前面是基类的data，后面紧跟的是此派生类自身定义的data，因此就必须知道类A与类B的内部细节，要不然编译器就无法来安排内存了。但是在处理参数以及参数返回值的时候，实际上并不需要知道这些信息，在此处定义的SomeFunctionCall()只需知道E是个class就足够了，并不需要知道类E中的data如长度等的具体细节。上面的代码应该改写成如下的形式，以减少依赖关系：

　　#include "a.h" // class A
　　#include "b.h" // class B
　　#include "c.h" // class C
　　#include "d.h" // class D
　　class E;
　　class X : public A, private B
　　{
　　　public:
　　E SomeFunctionCall(E someParameter);
　　　private:
　　D m_dInstance;
　　};

　　5、Never treat arrays polymorphically

　　不要把数组和多态一起使用，请看下面的例子。

　　class BST { ... };
　　class BalancedBST: public BST { ... };
　　void printBSTArray(ostream& s, const BST array[], int numElements)
　　{
　　for (int i = 0; i < numElements; ++i)
　　{
　　 s << array[i];
　　// this assumes an operator<< is defined for BST
　　}
　　}

　　BalancedBST bBSTArray[10];
　　printBSTArray(cout, bBSTArray, 10);

　　数组在内存中是一个连续的内存空间，而在数组中应该如何来定位一个元素呢？过程是这样的，编译器可以知道每个数据类型的长度大小，如果数组的index是0，则会自动去取第一个元素；如果是指定了某个index，编译器则会根据此index与该数据类型的长度自动去算出该元素的位置。

　　在printBSTArray()函数中，尽管传入的参数是BalancedBST类型，但由于其本来定义的类型是BST，那么它依然会根据BST来计算类型的长度。而通常派生类实例所占的内存要比基类实例所占的内存大一些，因此该程序在编译时会报错。请记住，永远不要把数组和C++的多态性放在一起使用。

　　6、Prevent exceptions from leaving destructors

　　析构函数中一定不要抛出异常。通常有两种情况会导致析构函数的调用，一种是当该类的对象离开了它的域，或delete表达式中一个该类对象的指针，另一种是由于异常而引起析构函数的调用。

　　如果析构函数被调用是由于exception引起，而此时在析构函数中又抛出了异常，程序会立即被系统终止，甚至都来不及进行内存释放。因此如果在析构函数中抛出异常的话，就很容易混淆引起异常的原因，且这样的软件也会让用户非常恼火。由于析构函数中很可能会调用其它的一些函数，所以在写析构函数的时候一定要注意，对这些函数是否会抛出异常要非常清楚，如果会的话，就一定要小心了。比如下面这段代码：

　　Session::~Session()
　 {
　　logDestruction(this);
　 }

　　比如logDestruction()函数可能会抛出异常，那么我们就应该采用下面这种代码的形式：

　　Session::~Session()
　 {
　　 try
　　{
　　　logDestruction(this);
　　 }
　　 catch (...)
　　{
　　 }
　}

　　这样程序出错的时候不会被立即关掉，可以给用户一些其它的选择，至少先让他把目前在做的工作保存下来。

　　7、Optimization:Remember the 80-20 rule

　　在软件界有一个20-80法则，其实这是一个很有趣的现象，比如一个程序中20%的代码使用了该程序所占资源的80%；一个程序中20%的代码占用了总运行时间的80%；一个程序中20%的代码使用了该程序所占内存的80%；在20%的代码上面需要花费80%的维护力量，等等。这个规律还可以被继续推广下去，不过这个规律无法被证明，它是人们在实践中观察得出的结果。从这个规律出发，我们在做程序优化的时候，就有了针对性。比如想提高代码的运行速度，根据这个规律可以知道其中20%的代码占用了80%的运行时间，因此我们只要找到这20%的代码，并进行相应的优化，那么我们程序的运行速度就可以有较大的提高。再如有一个函数，占用了程序80%的运行时间，如果把这个函数的执行速度提高10倍，那么对程序整体性能的提高，影响是非常巨大的。如果有一个函数运行时间只占总时间的1%，那就算把这个函数的运行速度提高1000倍，对程序整体性能的提高也是影响不大的。所以我们的基本思想就是找到占用运行时间最大的那个函数，然后去优化它，哪怕只是改进了一点点，程序的整体性能也可以被提高很多。

　　要想找出那20%的代码，我们的方法就是使用Profiler，它实际上是一些公司所开发的工具，可以检查程序中各个模块所分配内存的使用情况，以及每个函数所运行的时间等。常见的Profiler有Intel公司开发的VTune，微软公司开发的Visual Studio profiler，DevPartner from Compuware等

 我们在开篇就对简单性目标作了叙述，这里再稍微展开讨论一下。我们提出的简单标准，首先是外部接口简单，其次是内部结构简单。我们知道，类库是提供给上层应用程序使用的，也就是按照一定的接口规范，向上层提供一定的功能服务。接口设计得越简单，对上层用户来说就越方便，就越不容易产生Bug。我们可以注意到，流行的成功类库都是拥有简单接口的。为了使接口简单，常常不得不把有关具体实现的复杂性封装于类库内部，也就是说，关于简单性的设计原则，外部接口简单优先于内部实现简单。

高性能是C++语言优于其它OO语言的一个特性。C++的高性能应该首先归于它运行模式，和大多数OO语言不同，C++程序编译后直接产生本地平台代码（Native Code），理论上具备了可能的最大执行性能。另外的一个原因是主流的C++编译器都被设计得非常精巧，具有优越的代码优化能力。对于C++类库设计者来说，保持C++的高性能是一个重要目标。程序的高性能可以从两方面来评价，一是时间性能，以尽量短的时间来解决尽量多的业务；二是资源性能，以尽量少的资源消耗，包括CPU使用、内存占用、网络流量、磁盘空间等等，来维持正常的程序功能。提高性能的主要手段是数据结构、算法和程序体现结构的优化设计000-861 117-102 。

再说可移植性。C++的编译后输出代码是本地平台代码，因此C++本身不具有目标代码可移植性，C++的可移植性只能是源代码可移植性。源代码的可移植性是指，同一软件产品的全部或者部分源代码可以在不同的编译环境中进行编译（不需要编译的除外），并且其结果具有相同的品质特性（依优先顺序包括功能性、可靠性、可用性、性能性、可维护性等）。编译环境可以大致分为三个层次，最底层的是操作系统，也就是平台（Platform），其次是对源代码直接进行处理的编译器，然后是其它在编译过程中必需的中间件物品，如库文件等。我们知道C++虽然在语言规范上获得了统一（ISO/IEC），其编译器却是群雄割据的局面，具有代表性的有Borland C++系列（已经淡出市场），Microsoft的Visual Studio系列的C++编译器和GNU阵营的压轴产品gc中的g++。源代码经编译环境处理后产生的可执行代码的执行平台称为目标平台，不同的编译器的目标平台也不同，有的支持多平台，如g++，有的是单一平台，如Visual C++。对于类库设计者来说，想要获得完全的可移植性是非常困难的（除非是象STL这样被纳入语言规范的类库，因为不支持STL就是不支持标准的C++。即便如此不同的编译环境还是存在不同的STL实现版本，造成“一个类库多个实现”的局面），我们只能有选择地支持一部分环境。我们在开篇就已经说明，我们选择g++和Visual C++编译器，选择Linux和Windows 32位目标平台。

接下来我们来讨论C++类库设计的方法论。

首先，我们采用仅用头文件的类库设计方式（Header-only，STL的大多数实现版本都是采用Header-only的方式），也就是在头文件（.h）中声明和定义类，将其成员函数全部定义为内联函数，而不使用源程序文件（.cpp）。

我们知道在C语言的开发环境中，所谓库文件包含两个部分，头文件部分和二进制文件部分。根据二进制文件和用户目标文件结合方式的不同，又可分为静态链接文件和动态链接文件。这种库的构成模式已成为事实上的C语言开发环境的标准，绝大多数平台、绝大多数编译器都使用这种模式 117-301 190-721 。

然而C++语言开发环境，这种库构成模式遭遇到一个重大问题，就是符号命名问题。举例来说，C++允许多个函数可以被重载(Overload)，可以具有相同的名称，而通过参数列表不同被予以区别。这样就带来一个问题，编译完成的目标代码中怎样来区别这些在源代码中具有相同名称的函数？常见的做法是在编译器输出的函数的符号名称中加入描述类型信息的字符串，这种方法通常被称为名称装饰（Name decoration）或者名称糟化（Name mangling，这个术语真不好翻译，笔者的感觉是发明这个词的人觉得编译器把本来简单干净的符号给搞乱了）。比如说，g++3.4.4对于函数void func(int),其编译输出符号名称为_Z1funci，对于函数void func(int, int)，其输出符号名称为_Z1funcii，等等。但是，这种名称装饰规则没有统一规范，也就是说不同的编译器有各自不同的名称装饰规则，这样就导致不同的C++编译器只能识别自己的输出文件，而没有办法处理其他编译器的输出文件。因此，如果将C++程序制作成二进制的库文件，则其能够支持的开发环境只能限于原始的开发环境，基本上不具有多种开发环境间的通用性。

一个解决办法是将库文件保持在源代码形态（包括头文件和源文件），而不编译成二进制文件。比如STL的许多实现版本都是以头文件形式存在。这样虽然解决了名称装饰所带来的不可移植问题，但同时又会带来代码编译时间增长，源代码完全公开等问题。在C++的名称装饰规则未被统一之前，看起来这个问题是很难两全其美地解决了。

在本系列中，我们也仿照g++的STL实现方式，完全以头文件形式来编写类库。为什么不把代码放到源文件中去呢？主要原因是，头文件只需要用户使用包含指令（#include）就可以处理了，而源文件则需要配置到用户工程的编译目标列表中，和用户的源程序形成共同编译的形式，破坏了用户工程的编译目标的封闭性，比较麻烦而且不符合软件开发的一般习惯。

其次我们来讨论如何支持多平台。我们已经说过在本系列中我们的线程库支持Linux平台的Posix线程和Windows 32位平台的线程模式。我们可以参考C++的Pimpl“惯语”(Pimpl idiom，在Herb Sutter的《Exceptional C++》中有介绍)，采用2层类构造方式。上次类亦即接口类，为用户提供统一的类接口，在用户看来具有唯一的类行为定义；下层类亦即实现类，将接口类的行为定义转化为某个平台的具体实现。

　　 2.从标准头文件说起

　　某企业曾经给出如下的一道面试题：

　　面试题
　　为什么标准头文件都有类似以下的结构？

#ifndef __INCvxWorksh
#define __INCvxWorksh
#ifdef __cplusplus
extern "C" {
#endif
/*...*/
#ifdef __cplusplus
}
#endif
#endif /* __INCvxWorksh */

#ifdef __cplusplus
extern "C" {
#endif
#ifdef __cplusplus
}
#endif

　　extern int a;

void foo( int x, int y );

// 模块A头文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
int foo( int x, int y );
#endif

　　在模块B中引用该函数：

// 模块B实现文件　moduleB.cpp
#include "moduleA.h"
foo(2,3);

　　实际上，在连接阶段，连接器会从模块A生成的目标文件moduleA.obj中寻找_foo_int_int这样的符号！

　　 加extern "C"声明后的编译和连接方式

　　加extern "C"声明后，模块A的头文件变为：

// 模块A头文件　moduleA.h
#ifndef MODULE_A_H
#define MODULE_A_H
extern "C" int foo( int x, int y );
#endif

　　在模块B的实现文件中仍然调用foo( 2,3 )，其结果是：

　　（1）模块A编译生成foo的目标代码时，没有对其名字进行特殊处理，采用了C语言的方式；

　　（2）连接器在为模块B的目标代码寻找foo(2,3)调用时，寻找的是未经修改的符号名_foo。

　　如果在模块A中函数声明了foo为extern "C"类型，而模块B中包含的是extern int foo( int x, int y ) ，则模块B找不到模块A中的函数；反之亦然。

　　所以，可以用一句话概括extern “C”这个声明的真实目的（任何语言中的任何语法特性的诞生都不是随意而为的，来源于真实世界的需求驱动。我们在思考问题时，不能只停留在这个语言是怎么做的，还要问一问它为什么要这么做，动机是什么，这样我们可以更深入地理解许多问题）：
　　实现C++与C及其它语言的混合编程。
　　明白了C++中extern "C"的设立动机，我们下面来具体分析extern "C"通常的使用技巧。
　　 4.extern "C"的惯用法

　　（1）在C++中引用C语言中的函数和变量，在包含C语言头文件（假设为cExample.h）时，需进行下列处理：

extern "C"
{
#include "cExample.h"
}

　　而在C语言的头文件中，对其外部函数只能指定为extern类型，C语言中不支持extern "C"声明，在.c文件中包含了extern "C"时会出现编译语法错误。

　　笔者编写的C++引用C函数例子工程中包含的三个文件的源代码如下：

/* c语言头文件：cExample.h */
#ifndef C_EXAMPLE_H
#define C_EXAMPLE_H
extern int add(int x,int y);
#endif
/* c语言实现文件：cExample.c */
#include "cExample.h"
int add( int x, int y )
{
return x + y;
}
// c++实现文件，调用add：cppFile.cpp
extern "C"
{
#include "cExample.h"
}
int main(int argc, char* argv[])
{
add(2,3);
return 0;
}

　　如果C++调用一个C语言编写的.DLL时，当包括.DLL的头文件或声明接口函数时，应加extern "C" {　}。

　　（2）在C中引用C++语言中的函数和变量时，C++的头文件需添加extern "C"，但是在C语言中不能直接引用声明了extern "C"的该头文件，应该仅将C文件中将C++中定义的extern "C"函数声明为extern类型。
　　笔者编写的C引用C++函数例子工程中包含的三个文件的源代码如下：70-210 1Y0-327 

//C++头文件 cppExample.h
#ifndef CPP_EXAMPLE_H
#define CPP_EXAMPLE_H
extern "C" int add( int x, int y );
#endif
//C++实现文件 cppExample.cpp
#include "cppExample.h"
int add( int x, int y )
{
return x + y;
}
/* C实现文件 cFile.c
/* 这样会编译出错：#include "cExample.h" */
extern int add( int x, int y );
int main( int argc, char* argv[] )
{
add( 2, 3 );
return 0;
}

　　如果深入理解了第3节中所阐述的extern "C"在编译和连接阶段发挥的作用，就能真正理解本节所阐述的从C++引用C函数和C引用C++函数的惯用法。对第4节给出的示例代码，需要特别留意各个细节。