我个人使用c++的风格总是把类声明放在包含文件中，定义放在。cpp文件中，这很像Loki对c++头文件的回答，代码分离。不可否认，我喜欢这种风格的部分原因可能与我花了这么多年来编写Modula-2和Ada有关，这两者都有类似的规范文件和主体文件方案。
我有一个同事，他比我更了解c++，他坚持认为所有c++声明都应该尽可能地在头文件中包含定义。他并不是说这是一种有效的替代风格，甚至不是一种稍微更好的风格，而是说这是一种新的普遍接受的风格，现在每个人都在使用c++。
我不像以前那么灵活了，所以在我看到更多的人和他在一起之前，我并不急于加入他的行列。那么这个习语到底有多普遍呢?
只是给答案一些结构:现在的方式™，非常常见，有点常见，不常见，还是疯狂?
当前回答
这难道不是取决于系统的复杂性和内部约定吗?
目前，我正在研究一个非常复杂的神经网络模拟器，我期望使用的公认风格是:
classname.h中的类定义 classnameCode.h中的类代码 classname.cpp中的可执行代码
这将用户构建的模拟从开发人员构建的基类中分离出来，在这种情况下效果最好。
但是，如果有人在图形应用程序或其他目的不是为用户提供代码库的应用程序中这样做，我会感到惊讶。
其他回答
如果这个新方法真的是方法，我们可能在我们的项目中遇到了不同的方向。
因为我们尽量避免在头文件中出现不必要的东西。这包括避免头级联。头文件中的代码可能需要包含一些其他头文件，而这些头文件又需要另一个头文件，以此类推。如果我们被迫使用模板，我们尽量避免在标题中使用太多模板。
如果适用，我们还使用“不透明指针”模式。
通过这些实践，我们可以比大多数同行更快地构建。是的……更改代码或类成员不会导致巨大的重构。
通常，当编写一个新类时，我会把所有的代码放在类中，所以我不必在另一个文件中寻找它。在一切正常工作之后，我将方法的主体分解到cpp文件中，将原型留在hpp文件中。
这难道不是取决于系统的复杂性和内部约定吗?
目前，我正在研究一个非常复杂的神经网络模拟器，我期望使用的公认风格是:
classname.h中的类定义 classnameCode.h中的类代码 classname.cpp中的可执行代码
这将用户构建的模拟从开发人员构建的基类中分离出来，在这种情况下效果最好。
但是，如果有人在图形应用程序或其他目的不是为用户提供代码库的应用程序中这样做，我会感到惊讶。
为了增加更多的乐趣，你可以添加.ipp文件，其中包含模板实现(包含在.hpp中)，而.hpp包含接口。
除了模板化的代码(取决于项目，这可能是大部分或少数文件)，还有正常的代码，这里最好将声明和定义分开。在需要的地方也提供前向声明——这可能会影响编译时间。
我把所有实现都放在类定义之外。我想把doxygen注释从类定义中删除。
