我个人使用c++的风格总是把类声明放在包含文件中，定义放在。cpp文件中，这很像Loki对c++头文件的回答，代码分离。不可否认，我喜欢这种风格的部分原因可能与我花了这么多年来编写Modula-2和Ada有关，这两者都有类似的规范文件和主体文件方案。
我有一个同事，他比我更了解c++，他坚持认为所有c++声明都应该尽可能地在头文件中包含定义。他并不是说这是一种有效的替代风格，甚至不是一种稍微更好的风格，而是说这是一种新的普遍接受的风格，现在每个人都在使用c++。
我不像以前那么灵活了，所以在我看到更多的人和他在一起之前，我并不急于加入他的行列。那么这个习语到底有多普遍呢?
只是给答案一些结构:现在的方式™，非常常见，有点常见，不常见，还是疯狂?
当前回答
恕我直言，他只有在做模板和/或元编程时才有价值。前面已经提到了将头文件限制为声明的很多原因。他们只是…头。如果您希望包含代码，则将其编译为库并将其链接起来。
其他回答
通常，当编写一个新类时，我会把所有的代码放在类中，所以我不必在另一个文件中寻找它。在一切正常工作之后，我将方法的主体分解到cpp文件中，将原型留在hpp文件中。
我经常会把琐碎的成员函数放到头文件中，以允许它们内联。但是将整个代码体放在那里，只是为了与模板保持一致?那完全是胡说八道。
记住:愚蠢的一致性是心胸狭窄的妖怪。
你的同事错了，通常的方法是把代码放在。cpp文件(或任何你喜欢的扩展名)中，并在头文件中声明。
将代码放在头文件中偶尔会有一些好处，这可以让编译器更聪明地进行内联。但与此同时，它会破坏编译时间，因为所有代码在每次被编译器包含时都必须被处理。
最后，当所有的代码都是头部时，循环对象关系(有时是需要的)通常是令人讨厌的。
总之，你是对的，他是错的。
编辑:我一直在思考你的问题。在一种情况下，他说的是真的。模板。许多较新的“现代”库，如boost，大量使用模板，通常是“头文件”。但是，只有在处理模板时才应该这样做，因为这是处理模板时的唯一方法。
编辑:有些人想要更多的澄清，这里有一些关于写“只有头”代码的缺点的想法:
If you search around, you will see quite a lot of people trying to find a way to reduce compile times when dealing with boost. For example: How to reduce compilation times with Boost Asio, which is seeing a 14s compile of a single 1K file with boost included. 14s may not seem to be "exploding", but it is certainly a lot longer than typical and can add up quite quickly when dealing with a large project. Header only libraries do affect compile times in a quite measurable way. We just tolerate it because boost is so useful.
此外，还有许多事情不能仅在头文件中完成(甚至boost也有一些库，您需要链接到某些部分，如线程、文件系统等)。一个主要的例子是你不能在只有头的库中有简单的全局对象(除非你求助于讨厌的单例)，因为你会遇到多个定义错误。注意:c++ 17的内联变量将使这个特殊的例子在未来可行。
最后一点，当使用boost作为仅头代码的示例时，经常会忽略一个巨大的细节。
Boost是库，而不是用户级代码。所以它不会经常变化。在用户代码中，如果你把所有东西都放在头文件中，每一个小的改变都会导致你不得不重新编译整个项目。这是对时间的巨大浪费(对于那些在不同的编译器之间不进行更改的库来说，情况并非如此)。当你在头文件/源文件之间拆分时，更好的是，使用前向声明来减少包含，你可以在一天内节省数小时的重新编译时间。
有一天，c++程序员们就《路》达成一致，羊羔将和狮子躺在一起，巴勒斯坦人将拥抱以色列人，猫和狗将被允许结婚。
在这一点上，.h和.cpp文件之间的分离基本上是任意的，这是编译器优化很久以前的遗留问题。在我看来，声明属于头文件，定义属于实现文件。但是，那只是习惯，不是宗教。
你的同事可能知道的是，大多数c++代码都应该被模板化，以实现最大的可用性。如果它是模板化的，那么一切都需要在一个头文件中，以便客户端代码可以看到它并实例化它。如果它对Boost和STL来说足够好，它对我们来说就足够好了。
我不同意这种观点，但这可能是它的来源。
