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

Question

最近我开始将越来越多的函数放入头文件中，主要是为了方便起见。 但我担心我可能会过度使用它，我的标题充满了包含，我不确定这是不是一个好主意。

将函数移出头文件或将其移入头文件有哪些经验法则？

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

编辑：

我想从我的角度概述内联（自然）头函数与实现函数的优缺点是有帮助的：

专业内联：

• 更干净/简洁。
• 不需要签名重复。
• 无需更改任何Makefile以链接新文件。
• 即时启动模板参数的能力。

反对内联：

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

根据这一点，将几乎所有函数放在头文件中似乎是一个好主意，我相信这与STL和Boost正在做的非常接近（尽管这些是库，而不是我的代码）。

Answer 1

我最不可侵犯的规则之一：只有头文件中允许内联的函数体。 在链接阶段，还有其他任何问题需要解决多个定义问题。

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

Answer 2

我的经验法则是“不在标题中，除非你必须这样做”。 为方便起见，您是否发现编译时间增加了？

Answer 3

有一些明显的技术方面 - 模板和内联函数必须在标题中 - 来自多个翻译单元的标题必须警惕单一定义规则 - 更直接地说，你想要一个血腥的理由甚至考虑放出一个 - 标题中的行功能实现，我想不出任何时候我都被诱惑了。

所以，问题归结为：

内联标题与实现文件中的外联？

影响因素：

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

一句话：如果你发现自己越来越多地做这件事，那么它显然对你有用，没有特别的理由认为你会被烧焦。 留意潜在的问题，但不要基于一些假设的和不太可能实现的问题过度设计出来的东西。

Answer 4

一个好的编码标准将告诉您在源（cpp）文件中实现方法和函数。

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

Answer 5

由于这已被标记为C++ ，为什么不将它们分成逻辑class ？

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

Answer 6

我使用的两个规则是

1）如果它是内联函数

2）如果它是模板功能。

Answer 7

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

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

我从不使用inline因为编译器不保证。