头文件中的C ++代码
我对C ++的个人风格总是将类声明放在包含文件中，并将定义放在.cpp文件中，这非常类似于Loki对C ++头文件代码分离的回答。 无可否认，我喜欢这种风格的部分原因可能与我花费在编码Modula-2和Ada上的所有年份有关，它们都与规范文件和正文文件有相似的方案。
我有一个同事，比C ++更懂C ++，他坚持所有的C ++声明都应该尽可能在头文件中包含这些定义。 他并不是说这是一种有效的替代风格，或者说是一种稍微好一点的风格，但是这是每个人现在用于C ++的新的普遍接受的风格。
我没有以前那么灵活，所以我并不急于拼命追赶他，直到我看到更多的人在他身边。 那这个成语真的有多常见？
只是为了给答案一些结构：现在是否是方式 ，很常见，有点常见，不常见，或者错误的疯狂？
你的同事是错误的，常见的方式是始终将代码放入.cpp文件（或任何你喜欢的扩展名）和头文件中的声明中。
偶尔有一些优点将代码放在头文件中，这可以让编译器更聪明地内联。 但是与此同时，它可能会破坏您的编译时间，因为编译器每次都要处理所有代码。
最后，当所有的代码都是标题时，通常会有令人讨厌的循环对象关系（有时候是期望的）。
底线，你是对的，他错了。
编辑：我一直在想你的问题。 有一种情况是他所说的是真实的。 模板。 许多更新的“现代”库如boost会大量使用模板，并且通常只是“仅标头”。 但是，只有在处理模板时才应该这样做，因为这是处理模板时唯一的方法。
编辑：有些人想要多一点澄清，这里有一些关于编写“仅头文件”代码的缺点的想法：
如果你四处搜索，你会看到很多人试图找到一种方法来减少处理boost时的编译时间。 例如：如何通过Boost Asio减少编译时间，Booster Asio可以看到一个包含boost的单个1K文件的14s编译。 14可能看起来不是“爆炸”，但它肯定比典型的要长很多，并且可以很快加起来。 在处理大型项目时。 只有头文件的库会以相当可测量的方式影响编译时间。 我们只是容忍它，因为提升非常有用。
此外，还有很多事情不能在头文件中完成（即使boost需要链接某些部分（如线程，文件系统等）的库）。 一个主要的例子是，你不能只在标题头库中拥有简单的全局对象（除非你诉诸单身的憎恶），因为你会遇到多个定义错误。 注意： C ++ 17的内联变量将使这个特定的示例在未来可行。
作为最后一点，当使用boost作为仅头部代码的示例时，往往会忽略一个巨大的细节。
Boost是库，而不是用户级代码。 所以它不会经常改变。 在用户代码中，如果将所有内容都放在标题中，每一个小改动都会导致你不得不重新编译整个项目。 这是一个巨大的浪费时间（而不是从编译到编译的库不变）。 当你在标题/源代码之间进行分割并且更好的时候，使用前向声明来减少包含，你可以在整天添加时节省几小时的重新编译时间。
C ++编码人员在The Way上达成一致，羊羔会躺在狮子身边，巴勒斯坦人会拥抱以色列人，猫和狗会被允许结婚。
在这个时候，.h和.cpp文件之间的分离通常是任意的，这是编译器优化的遗迹。 在我看来，声明属于标题，定义属于实现文件。 但是，那只是习惯，而不是宗教。
在头文件中的代码通常是一个坏主意，因为当你改变实际代码而不是声明时，它会强制重新编译包含头文件的所有文件。 它也会减慢编译速度，因为你需要解析每个包含头文件的代码。
在头文件中使用代码的原因在于，关键字inline通常需要正确使用以及使用在其他cpp文件中实例化的模板时。
链接地址: http://www.djcxy.com/p/72903.html下一篇: C++ SFINAE examples?