文档介绍:: .
者注:能依赖声明的就不要依赖定义。
3 . 内联函数
只有当函数只有1 0 行甚至更少时才会将其定义为内联函数(inline function),
定 义 (Definition):当函数被声明为内联函数之后,编译器可能会将其内联展开,无需按
通常的函数调用机制调用内联函数。
优 点 :当函数体比较小的时候,内联该函数可以令目标代码更加高效。对于存取函数
(accessor、mutator)以及其他一些比较短的关键执行函数。
缺点:滥用内联将导致程序变慢,内联有可能是目标代码量或增或减,这取决于 被内联的函
数的大小。内联较短小的存取函数通常会减少代码量,但内联一个很大的函数(译者注:如
果编译器允许的话)将戏剧性的增加代码量。在现代处理器上,由于 更好的利用指令缓存
(i nstruct ion cache),小巧的代码往往执行更快。
结论:一个比较得当的处理规则是,不要内联超过10行的函数。对于 析构函数应慎重对待,析构函数往往比其表面看起来要长,因为有一些隐式成员和基类析构函数(如果有的话)被
调 用 !
另一有用的处理规则:内联那些包含循环或switch语句的函数是得不偿失的,除非在大多
数情况下,这些循环或switch语句从不执行。
重要的是,虚函数和递归函数即使被声明为内联的也不一定就是内联函数。通常,递归函数
不应该被声明为内联的(译者注:递归调用堆栈的展开并不像循环那么简单,比如递归层数
在编译时可能是未知的,大多数编译器都不支持内联递归函数)。析构函数内联的主要原因
是其定义在类的定义中,为了方便抑或是对其行为给出文档。
4 . 文件
复杂的内联函数的定义,应放在后缀名为的头文件中。
在头文件中给出内联函数的定义,可令编译器将其在调用处内联展开。然而,实现代码应完
,我们不希望. h 文件中出现太多实现代码,除非这样做在可读性和效率上
有明显优势。
如果内联函数的定义比较短小、逻辑比较简单,其实现代码可以放在. h 文件中。例如,存
取函数的实现理所当然都放在类定义中。出于 实现和调用的方便,较复杂的内联函数也可以
放到. h 文件中,如果你觉得这样会使头文件显得笨重,还可以将其分离到单独的中。这样
即把实现和类定义分离开来,当需要时包含实现所在的即可。
文件还可用于 函数模板的定义,从而使得模板定义可读性增强。
要提醒的一点是,和其他头文件一样,也需要#define保护。
5 . 函 数 参 数 顺 序 (Function Parameter Ordering)
定义函数时,参数顺序为:输入参数在前,输出参数在后。
C/C++函数参数分为输入参数和输出参数两种,有时输入参数也会输出(译者注:值被修改
时)。输入参数一般传值或常数引用(const references), 输出参数或输入/输出参数为非
常 数 指 针 (non-const po inters), 对参数排序时,将所有输入参数置于输出参数之前。不
要仅仅因为是新添加的参数,就将其置于最后,而应该依然置于输出参数之前。
这一点并不是必须遵循的规则,输入/输出两用参数(通常是类/结构体变量)混在其中,会
使得规则难以遵循。
6 . 包含文件的名称及次序
将包含次序标准化可增强可读性、避 免 隐 藏 依 赖 (hidden dependencies,译者注:隐藏依
赖主要是指包含的文件中编译时),次序如下:C 库 、C++库 、、。
项目内头文件应按照项目源代码目录树结构排列,并且避免使用UNIX文