首页 > 代码库 > Google C++ style guide——头文件
Google C++ style guide——头文件
1.#define保护
使用#define防止头文件被多重包括。命名格式为:<PROJECT>_<PATH>_<FILE>_H_
比如,foo中的头文件foo/src/bar/baz.h
#ifndef FOO_BAR_BAZ_H_
#define FOO_BAR_BAZ_H_
...
#endif //FOO_BAR_BAZ_H_
2.头文件依赖
使用前置声明尽量降低.h文件里#include的数量。
头文件被更改时,须要又一次编译。那些包括了该头文件的代码也须要又一次编译,因此,我们应该实现尽可能少的在头文件里包括头文件。
前置声明能够明显的降低须要包括的头文件数量。假如你在一个头文件里须要用到类File,但不须要訪问File的声明,则头文件仅仅需前置声明class File。
在下面情况能够使用类Foo而无需訪问类的定义。
1)将数据成员类型声明为Foo *或者Foo &;
2)參数、返回值类型为Foo的函数仅仅是声明(不在头文件内定义实现);
3)静态数据成员的类型能够被声明为Foo(由于静态数据成员的定义在类定义之外)。
假设你的类是Foo的子类,或者含有类型为Foo的非静态数据成员,则必须为之包括头文件。
有时,使用指针成员替代对象成员的确更有意义。可是,这种做法会减少代码可读性及运行效率。假设只为了少包括头文件,还是不要替代比較好。
当然,.cc或者.cpp不管怎样都须要所使用类的定义部分,自然也就会包括若干头文件。
3.内联函数
仅仅有当函数仅仅有10行甚至更少时才会将其定义为内联函数。
当函数被声明为内联函数之后,编译器可能会将其内联展开,无需按通常的函数调用机制调用内联函数。
长处:当函数体比較小的时候,内联该函数能够令目标代码更加高效。比如存取函数,以及其它一些比較短的关键运行函数。
缺点:滥用内联将导致程序变慢,内联有可能使目标代码量或增或建,这取决与被内联的函数的大小。内联较短小的存取函数一般会降低代码量,但内联一个非常大的函数(假设编译器同意的话),将显著添加?代码量。
在如今处理器上,因为更好的利用指令缓存,小巧的代码往往运行更快。
一个比較得当的处理规则是,不要内联超过10行的函数。对于析构函数应谨慎对待,析构函数往往比其表面看起来要长,由于有一些隐式成员和基类析构函数(假设有的话)被调用。
虚函数和递归函数即使被声明为内联的,也不一定就是内联函数。通常,递归函数不应该被声明为内联的(递归调用堆栈的展开并不像循环那么简单,比方递归层数在编译时可能是未知的,大多数编译器都不支持内联递归函数)。析构函数内联的主要原因是其定义在类的定义中,为了方便抑或是对其行为给出文档。
4.-inl.h文件
复杂的内联函数的定义,应放在后缀名为-inl.h的头文件里。
在头文件里给出内联函数的定义,可令编译器将其在调用出内联展开。然后,实现代码应全然放到.cc文件里,我们不希望.h文件里出现太多实现代码,除非这样做在可读性和效率上有明显优势。
假设内联函数的定义比較短小、逻辑比較简单,事实上现代码能够放在.h文件里。比如,存取函数的实现理所当然都放在类定义中。处于实现和调用的方便,较复杂的内联函数也能够放到.h文件里,假设你认为这样会使头文件显得笨重,还能够将其分离到单独的-inl.h中。这样即把实现和类定义分离开来,当须要时包括实现所在的-inl.h就可以。
相同的,-inl.h也是须要#define保护的。
5.函数參数顺序
定义函数事,參数顺序为:输入參数在前,输出參数在后。
6.将包括次序标准化可增强可读性、避免隐藏依赖,次序例如以下:C库、C++库、其它库的.h、项目内的.h。
同样文件夹下头文件按字母序是不错的选择。
Google C++ style guide——头文件