将函数放入头文件的经验法则

Question

最近我开始将越来越多的函数放入头文件中，主要是为了方便。但我担心我可能做得太过分了，我的标题充满了包含内容，我不确定这是否是一个好主意。

将函数移出或移入头文件的经验法则是什么？

如果您想知道，我说的是开发应用程序，而不是库。

编辑：

如果我从我的角度概述内联（自然）标头函数与实现函数的优缺点，我想这会很有帮助：

Pro inline：

• 更干净/简洁。
• 无需复制签名。
• 无需更改任何 Makefile 即可链接新文件。
• 即时引入模板参数的能力。

Contra inline：

• 增加编译时间（我不在乎那么多）
• 许多包含在标头中（如果他们使用防护，就不应该是一个大问题）

据此，这似乎是一个好主意将几乎每个函数都放在标头中，我相信这与 STL 和 Boost 所做的非常接近（尽管它们是库，而不是我的代码）。

Answer 1

我最不可违反的规则之一：头文件中只允许内联函数体。其他任何事情都会在链接阶段遇到多个定义的麻烦。

标题应该主要用于声明而不是定义。我对该规则有例外（灵活类型），但它们都不涉及非内联函数体。

Answer 2

我的经验法则是“除非必须，否则不要在标题中。”至于方便性，您觉得增加编译时间方便吗？

Answer 3

有几个明显的技术方面
- 模板和内联函数必须位于标题中
- 多个翻译单元中包含的标题必须警惕“单一定义”规则
- 更坦白地说，你需要一个充分的理由来考虑在标头中放入一个外线函数实现，而且我想不出任何时候我都受到过诱惑。

所以，问题归结为：

      头文件中的内联与实现文件中的外联？

因素：

• 您说您正在设计应用程序级代码而不是库，因此，您（当前）不必担心其他团队会依赖您的代码，也不必通过保持实现脱节来最大程度地减少重新编译（而不是重新链接）的需要
  • 但是，如果您正在编写有可能对其他团队有用的优秀代码，那么您可能会发现自己希望将实现保持私有
• 内联与外联通常代表大约一个顺序 -琐碎数据获取/设置函数的巨大开销...如果您有从性能关键代码中重复调用的函数，那么您有理由更喜欢内联
• 标头内实现（特别是与声明混合在一起时）通常会混淆 API ，但有时实际上使代码更加自我记录
• 本地化并删除冗余（组合声明/定义）肯定会消除打字错误/错误的可能性，并且通常可以提高生产力

底线：如果您发现自己越来越多地这样做，那么它显然是为了你，没有特别的理由认为你会被烧伤。密切关注潜在的问题，但不要基于一些假设的和不太可能实现的问题而过度设计这些东西。

Answer 4

良好的编码标准将告诉您在源 (cpp) 文件中实现方法和函数。

如果您愿意，可以在标头中实现模板和内联函数。

Answer 5

既然它已被标记为C++，为什么不将它们分成逻辑类呢？

通常，我在头文件中有一个 class 声明，并且它的定义在相应的源文件中。

Answer 6

我使用的两个规则是

1) 如果它是内联函数

2) 如果它是模板函数。

Answer 7

首先，模板函数必须放在标题中。

此外，具有空主体的函数，例如默认构造函数或默认但虚拟析构函数，可以放在标头中。

我从不使用内联，因为编译器不能保证这一点。