C++风格_头文件

每一个 .cpp的资源文件都有一个与之对应的 .h头文件。main.cpp与系统自动生成项目除外。

1、防止多重包含

以下两种方式选择其一即可：

1）、头文件必须加

所有头文件都应该使用 #define 来防止头文件被多重包含, 命名格式当是: _< PROJECT >_< PATH >_< FILE >_H_ .

#ifndef _MYLAB_INIT_H_#define _MYLAB_INIT_H_...#endif // _MYLAB_INIT_H_

所有字母大写，在开头结尾处加下划线 _

2）、不用#pragma once

这种方式相比较1）不能清晰地体现出依赖的关系。

2、前置声明

尽可能地避免使用前置声明。使用 #include 包含需要的头文件即可。
定义：

所谓「前置声明」（forward declaration）是类、函数和模板的纯粹声明，没伴随着其定义.
优点：

• 前置声明能够节省编译时间，多余的#include会迫使编译器展开更多的文件，处理更多的输入。
• 前置声明能够节省不必要的重新编译的时间。#include 使代码因为头文件中无关的改动而被重新编译多次。

缺点：

• 前置声明隐藏了依赖关系，头文件改动时，用户的代码会跳过必要的重新编译过程。
• 前置声明可能会被库的后续更改所破坏。前置声明函数或模板有时会妨碍头文件开发者变动其 API. 例如扩大形参类型，加个自带默认参数的模板形参等等。
• 前置声明来自命名空间 std::的symbol时，其行为未定义。
  很难判断什么时候该用前置声明，什么时候该用#include 。极端情况下，用前置声明代替includes甚至都会暗暗地改变代码的含义：

// b.h:struct B {};struct D : B {}// good_user.cc : #include "b.h"void f(B*);void f(void*);void test(D* x) { f(x); }  // calls f(B*)

如果 #include 被 B 和 D 的前置声明替代， test() 就会调用 f(void*) .
- 前置声明了不少来自头文件的 symbol 时，就会比单单一行的 include 冗长。
- 仅仅为了能前置声明而重构代码（比如用指针成员代替对象成员）会使代码变得更慢更复杂.

结论：

• 尽量避免前置声明那些定义在其他项目中的实体.
• 函数：总是使用 #include.
• 类模板：优先使用#include.

3、内联函数

只有当函数只有 10 行甚至更少时才将其定义为内联函数.
定义:

当函数被声明为内联函数之后, 编译器会将其内联展开, 而不是按通常的函数调用机制进行调用.
优点:

只要内联的函数体较小, 内联该函数可以令目标代码更加高效. 对于存取函数以及其它函数体比较短, 性能关键的函数, 鼓励使用内联.
缺点:

滥用内联将导致程序变得更慢. 内联可能使目标代码量或增或减, 这取决于内联函数的大小. 内联非常短小的存取函数通常会减少代码大小, 但内联一个相当大的函数将戏剧性的增加代码大小. 现代处理器由于更好的利用了指令缓存, 小巧的代码往往执行更快。
结论:

一个较为合理的经验准则是, 不要内联超过 10 行的函数. 谨慎对待析构函数, 析构函数往往比其表面看起来要更长, 因为有隐含的成员和基类析构函数被调用!

另一个实用的经验准则: 内联那些包含循环或 switch 语句的函数常常是得不偿失 (除非在大多数情况下, 这些循环或 switch 语句从不被执行).

有些函数即使声明为内联的也不一定会被编译器内联, 这点很重要; 比如虚函数和递归函数就不会被正常内联. 通常, 递归函数不应该声明成内联函数.（YuleFox 注: 递归调用堆栈的展开并不像循环那么简单, 比如递归层数在编译时可能是未知的, 大多数编译器都不支持内联递归函数). 虚函数内联的主要原因则是想把它的函数体放在类定义内, 为了图个方便, 抑或是当作文档描述其行为, 比如精短的存取函数.

4、#include的路径及顺序

使用标准的头文件包含顺序可增强可读性, 避免隐藏依赖: 相关头文件, C 库, C++ 库, 其他库的 .h, 本项目内的 .h.

项目内头文件应按照项目源代码目录树结构排列, 避免使用 UNIX 特殊的快捷目录 . (当前目录) 或 .. (上级目录). 例如,
google-awesome-project/src/base/logging.h应该按如下方式包含:

 #include "base/logging.h"

又如, dir/foo.cc或 dir/foo_test.cc 的主要作用是实现或测试 dir2/foo2.h的功能, foo.cc中包含头文件的次序如下:

• 1、dir2/foo2.h (优先位置, 详情如下)
• 2、C 系统文件
• 3、C++ 系统文件
• 4、其他库的 .h 文件
• 5、本项目内 .h 文件

这种优先的顺序排序保证当 dir2/foo2.h遗漏某些必要的库时， dir/foo.cc 或 dir/foo_test.cc 的构建会立刻中止。因此这一条规则保证维护这些文件的人们首先看到构建中止的消息而不是维护其他包的人们。

dir/foo.cc和dir2/foo2.h通常位于同一目录下 (如 base/basictypes_unittest.cc和 base/basictypes.h), 但也可以放在不同目录下.

按字母顺序分别对每种类型的头文件进行二次排序是不错的主意。注意较老的代码可不符合这条规则，要在方便的时候改正它们。

您所依赖的符号 (symbols) 被哪些头文件所定义，您就应该包含（include）哪些头文件，前置声明 (forward declarations) 情况除外。比如您要用到 bar.h 中的某个符号, 哪怕您所包含的foo.h已经包含了 bar.h, 也照样得包含bar.h, 除非foo.h 有明确说明它会自动向您提供bar.h中的symbol. 不过，凡是 cc 文件所对应的「相关头文件」已经包含的，就不用再重复包含进其 cc 文件里面了，就像 foo.cc 只包含 foo.h就够了，不用再管后者所包含的其它内容。

举例来说, google-awesome-project/src/foo/internal/fooserver.cc 的包含次序如下:

 #include "foo/public/fooserver.h" // 优先位置 #include < sys/types.h > #include < unistd.h > #include < hash_map > #include < vector > #include "base/basictypes.h" #include "base/commandlineflags.h" #include "foo/public/bar.h"

例外：

有时，平台特定（system-specific）代码需要条件编译（conditional includes），这些代码可以放到其它 includes 之后。当然，您的平台特定代码也要够简练且独立，比如：

 #include "foo/public/fooserver.h" #include "base/port.h"  // For LANG_CXX11. #ifdef LANG_CXX11 #include <initializer_list> #endif  // LANG_CXX11