我个人使用c++的风格总是把类声明放在包含文件中，定义放在。cpp文件中，这很像Loki对c++头文件的回答，代码分离。不可否认，我喜欢这种风格的部分原因可能与我花了这么多年来编写Modula-2和Ada有关，这两者都有类似的规范文件和主体文件方案。
我有一个同事，他比我更了解c++，他坚持认为所有c++声明都应该尽可能地在头文件中包含定义。他并不是说这是一种有效的替代风格，甚至不是一种稍微更好的风格，而是说这是一种新的普遍接受的风格，现在每个人都在使用c++。
我不像以前那么灵活了，所以在我看到更多的人和他在一起之前，我并不急于加入他的行列。那么这个习语到底有多普遍呢?
只是给答案一些结构:现在的方式™，非常常见，有点常见，不常见，还是疯狂?
当前回答
我认为把所有的函数定义都放在头文件中是非常荒谬的。为什么?因为头文件被用作类的PUBLIC接口。这是“黑匣子”的外部。
当您需要查看一个类以引用如何使用它时，您应该查看头文件。头文件应该给出它能做什么的列表(注释以描述如何使用每个函数的细节)，它应该包括一个成员变量列表。它不应该包括每个单独的函数是如何实现的，因为那是一船不必要的信息负载，只会使头文件混乱。
其他回答
你的同事可能知道的是，大多数c++代码都应该被模板化，以实现最大的可用性。如果它是模板化的，那么一切都需要在一个头文件中，以便客户端代码可以看到它并实例化它。如果它对Boost和STL来说足够好，它对我们来说就足够好了。
我不同意这种观点，但这可能是它的来源。
恕我直言，他只有在做模板和/或元编程时才有价值。前面已经提到了将头文件限制为声明的很多原因。他们只是…头。如果您希望包含代码，则将其编译为库并将其链接起来。
这难道不是取决于系统的复杂性和内部约定吗?
目前，我正在研究一个非常复杂的神经网络模拟器，我期望使用的公认风格是:
classname.h中的类定义 classnameCode.h中的类代码 classname.cpp中的可执行代码
这将用户构建的模拟从开发人员构建的基类中分离出来，在这种情况下效果最好。
但是，如果有人在图形应用程序或其他目的不是为用户提供代码库的应用程序中这样做，我会感到惊讶。
通常，当编写一个新类时，我会把所有的代码放在类中，所以我不必在另一个文件中寻找它。在一切正常工作之后，我将方法的主体分解到cpp文件中，将原型留在hpp文件中。
我认为你的同事很聪明，你也是对的。
我发现把所有东西都放在头文件中的有用的事情是:
不需要写和同步头文件和源文件。 结构很简单，没有循环依赖迫使编码器做出“更好”的结构。 便携，易于嵌入到新项目中。
我同意编译时间的问题，但我认为我们应该注意到:
源文件的改变很可能会改变头文件，从而导致整个项目重新编译。 编译速度比以前快多了。而如果你的项目建设时间长、频率高，这可能说明你的项目设计存在缺陷。将任务分离到不同的项目和模块中可以避免这个问题。
最后，我只是想支持你的同事，只是在我个人看来。
