
之前一直没有全面的看过Google C++风格指南,现在很多公司进行C++开发都要求按照Google C++风格。在这个网站 有人已经把其翻译成中文。为了便于以后查看,下面的内容完全是来自于这个网站,只是把多个网页的内容整理放在了一起。
1.头文件:
通常每一个.cc文件都有一个对应的.h文件。也有一些常见例外,如单元测试代码和只包含main()函数的.cc文件。
#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_头文件依赖:能用前置声明的地方尽量不使用 #include.
当一个头文件被包含的同时也引入了新的依赖,一旦该头文件被修改,代码就会被重新编译。如果这个头文件又包含了其他头文件,这些头文件的任何改变都将导致所有包含了该头文件的代码被重新编译。因此,我们倾向于减少包含头文件,尤其是在头文件中包含头文件。
使用前置声明可以显著减少需要包含的头文件数量。举例说明:如果头文件中用到类 File,但不需要访问File类的声明,头文件中只需前置声明class File;而无须 #include "file/base/file.h"
不允许访问类的定义的前提下,我们在一个头文件中能对类Foo做哪些操作?
(1)、我们可以将数据成员类型声明为Foo *或Foo &.
(2)、我们可以将函数参数/返回值的类型声明为Foo(但不能定义实现).
(3)、我们可以将静态数据成员的类型声明为Foo,因为静态数据成员的定义在类定义之外.
反之,如果你的类是Foo的子类,或者含有类型为Foo的非静态数据成员,则必须包含Foo所在的头文件.
有时,使用指针成员(如果是scoped_ptr更好)替代对象成员的确是明智之选.然而,这会降低代码可读性及执行效率,因此如果仅仅为了少包含头文件还是不要这么做的好.
当然.cc文件无论如何都需要所使用类的定义部分,自然也就会包含若干头文件.
内联函数:只有当函数只有10行甚至更少时才将其定义为内联函数。
定义:当函数被声明为内联函数之后,编译器会将其内联展开,而不是按通常的函数调用机制进行调用。
优点:当函数体比较小的时候,内联该函数可以令目标代码更加高效。对于存取函数以及其它函数体比较短,性能关键的函数,鼓励使用内联。
缺点:滥用内联将导致程序变慢。内联可能使目标代码量或增或减,这取决于内联函数的大小。内联非常短小的存取函数通常会减少代码大小,但内联一个相当大的函数将戏剧性的增加代码大小。现代处理器由于更好的利用了指令缓存,小巧的代码往往执行更快。
结论:一个较为合理的经验准则是,不要内联超过10行的函数。谨慎对待析构函数,析构函数往往比其表面看起来要更长,因为有隐含的成员和基类析构函数被调用!
另一个实用的经验准则:内联那些包含循环或switch语句的函数常常是得不偿失(除非在大多数情况下,这些循环或switch语句从不被执行)。
有些函数即使声明为内联的也不一定会被编译器内联,这点很重要:比如虚函数和递归函数就不会被正常内联。通常,递归函数不应该声明成内联函数。(YuleFox注:递归调用堆栈的展开并不像循环那么简单,比如递归层数在编译时可能是未知的,大多数编译器都不支持内联递归函数)。虚函数内联的主要原因则是想把它的函数体放在类定义内,为了图个方便,抑或是当作文档描述其行为,比如精短的存取函数。
本文来自电脑杂谈,转载请注明本文网址:
https://www.pc-fly.com/a/jisuanjixue/article-35033-1.html
你牛
拉森号导弹驱逐舰是阿利伯克级宙斯盾驱逐舰