将函数放入头文件的经验规则
最近，我开始在头文件中添加越来越多的函数，主要是为了方便。但我担心我可能做得太过了，我的头充满了包含，我不确定这是否是一个好主意。
将函数从头文件移出或移到头文件时，您的经验规则是什么？
如果您想知道，我说的是开发应用程序，而不是库。
编辑：
我想，从我的角度概述内联(自然)头函数与实现函数的优缺点是有帮助的：
Pro内联：
更多的clean/concise.
- No需要签名，duplication.
- No需要更改任何Makefile来链接到新文件。
- 即时引入模板参数的能力。
Contra内联：
- 增加了编译时间(我不太在意)，
- 很多都包含在标题中(如果他们使用警卫，应该不是什么大问题)
根据这一点，将几乎所有函数都放在标题中似乎是个好主意，我相信这与STL和Boost的功能非常接近(尽管它们是库，而不是我的代码)。
回答 7
Stack Overflow用户
发布于 2011-05-20 06:38:13
我最不能违反的规则之一是:头文件中只允许内联的函数体。其他任何东西都是在链接阶段使用多个定义来自找麻烦。
标题应该主要留给声明而不是定义。我对该规则有例外(作为灵活的类型)，但它们中没有一个涉及非内联函数体。
Stack Overflow用户
发布于 2011-05-20 06:41:11
我的经验法则是“除非你必须这样做，否则不要在头上。”至于方便，你觉得增加编译时间方便吗？
Stack Overflow用户
发布于 2011-05-20 08:37:53
有几个明显的技术方面-模板和内联函数必须在标题中--来自多个翻译单元的标题必须对一个定义规则保持警惕--更直截了当地说，您甚至想要有一个非常好的理由来考虑将一个越线函数实现放在一个标头中，而且我甚至想不出有什么时候我会被诱惑。
因此，问题归结为：
头文件中的内联与实现文件中的越线？
因素：
您说您正在设计应用程序级代码而不是库，因此您不必(目前)担心其他团队依赖于您的代码，也不需要通过将实现保持在private行之外来最小化它们重新编译的需要(而不是重新链接)，但是如果您正在编写的好代码可能会对其他团队有用，那么您可能会发现自己希望保持实现
- 。
- 内联和离线通常代表一个数量级的开销，用于琐碎的数据获取/设置函数.如果您有从性能关键代码中反复调用的函数，那么您有理由更喜欢inlining
- in-header实现(特别是如果与声明混合在一起)经常会混淆API，但有时实际上会使代码更加self-documenting
- localisation，并且删除冗余(组合声明/定义)肯定会消除输入/错误的可能性，并且可以经常改进productivity
。
一句话:如果你发现自己做的越来越多，那么它显然是对你有用的，没有什么特别的理由认为你会被烧死。注意潜在的问题，但不要在一些假设的、不太可能成为现实的担忧的基础上过度设计一些东西。
https://stackoverflow.com/questions/6068292
复制相似问题
腾讯云开发者
