我的个人C ++风格一直是将类声明放在包含文件中，将定义放在.cpp文件中，非常像Loki对于 C ++ Header Files，Code Separation的回答中建议的那样。不可否认，我喜欢这种风格的原因可能与我花费的所有年份编写Modula-2和Ada有关，两者都具有规范和主体文件的类似方案。
我有一个比我更了解C ++的同事，他坚称所有C ++声明都应该在可能的情况下在头文件中直接包含定义。他并不是说这是一种有效的备用风格，甚至不是稍微好一点的风格，而是这是每个人现在都在为C ++使用的新普遍接受风格。
我不像以前那么灵活，所以我真的不急着爬上他的“车轮战车” ，直到我看到还有几个人和他一起上去。那么这个习惯用语到底有多常见？
只是为了给答案一些结构：它现在是The Way™，非常普遍，有些普遍，不太普遍还是很疯狂？
你的同事是错误的，通常的方式是把代码放在 .cpp 文件（或任何你喜欢的扩展名）中，把声明放在头文件中。
有时把代码放在头文件中的确有一些优点，这可以让编译器更聪明地内联。但与此同时，它也可能破坏你的编译时间，因为每次编译器包含代码时都必须处理所有代码。
最后，当所有代码都在头文件中时，循环对象关系（有时是期望的）经常会成为问题。
总之，你是正确的，他是错误的。
编辑：我考虑了你的问题。有一个情况是他说的是对的。模板。许多新的“现代”库如 boost 等大量使用模板，并且通常是“仅头文件”。然而，只有处理模板时才应该这样做，因为这是处理它们的唯一方法。
编辑：有些人想要更多的澄清，下面是有关编写“仅头文件”的缺点的一些想法：
如果你搜索一下，你会发现很多人试图找到一种减少处理 boost 时编译时间的方法。例如：如何通过 Boost Asio 减少编译时间，其中一个包含 boost 的单个 1K 文件的编译需要 14 秒。14 秒可能并不会爆炸，但它肯定比典型值要长得多，并且在处理大型项目时可以快速累积。仅头文件库确实以相当可测量的方式影响编译时间。我们只是容忍了它，因为 boost 很有用。
此外，有许多事情在头文件中无法完成（即使boost也需要链接到某些库，如线程、文件系统等的某些部分）。一个主要的例子是，在仅限头文件的库中无法使用简单的全局对象（除非您采用单例模式这样的可怕方法），否则会遇到多次定义错误。 注意：C++17中的内联变量将使未来可以实现此特定示例。
最后一点，当将boost作为仅限头文件代码的示例时，通常会忽略一个重要细节。
Boost是一个库，而不是用户级别的代码。因此，它不经常更改。在用户代码中，如果你把所有东西都放在头文件中，每个小改动都会导致你不得不重新编译整个项目。这是一种巨大的时间浪费（对于不会从一个编译到另一个编译发生变化的库而言不是这种情况）。当您将事物分割在头文件/源文件之间，并更好地使用前向声明以减少包含，您可以节省数小时的重新编译时间，这在一天内增加起来非常可观。
当C++程序员们达成共识时，HTML标记内的说法，羔羊将与狮子躺下，巴勒斯坦人将拥抱以色列人，猫和狗将被允许结婚。
.h和.cpp文件之间的分离在这个点上大多是任意的，是编译器优化的残余。在我看来，声明应该在头文件中，定义应该在实现文件中。但是，这只是习惯，不是教条。
在头文件中编写代码通常是一个不好的主意，因为当您更改实际代码而不是声明时，它会强制重新编译包含头文件的所有文件。这还会使编译速度变慢，因为您需要解析包含头文件的每个文件中的代码。
头文件中编写代码的原因之一是它通常需要使用关键字inline才能正常工作，并且在使用模板被实例化在其他cpp文件中时也需要。
我认为你的同事很聪明，你也是正确的。
我发现把所有东西都放在头文件中有以下几个好处：
不需要编写和同步头文件和源文件。
结构简单，没有循环依赖迫使程序员制定“更好”的结构。
易于移植到新项目中。
我确实同意编译时间的问题，但我认为我们应该注意：
更改源文件很可能会更改头文件，这将导致整个项目被重新编译。
编译速度比以前快得多。如果您有一个需要长时间和高频率构建的项目，则可能表明您的项目设计存在缺陷。将任务分解成不同的项目和模块可以避免此问题。
最后，我只是想支持您的同事，在我个人看来。
A<B>的主体，然后用户想要一个A<C>时会发生什么？ - jww// example_fwd.hpp
// Here necessary to forward declare the template class,
// you don't want people to declare them in case you wish to add
// another template symbol (with a default) later on
class MyClass;
template <class T> class MyClassT;
// example.hpp
#include "project/example_fwd.hpp"
// Those can't really be skipped
#include <string>
#include <vector>
#include "project/pimpl.hpp"
// Those can be forward declared easily
#include "project/foo_fwd.hpp"
namespace project { class Bar; }
namespace project
{
class MyClass
{
public:
struct Color // Limiting scope of enum
{
enum type { Red, Orange, Green };
};
typedef Color::type Color_t;
public:
MyClass(); // because of pimpl, I need to define the constructor
private:
struct Impl;
pimpl<Impl> mImpl; // I won't describe pimpl here :p
};
template <class T> class MyClassT: public MyClass {};
} // namespace project
// example_impl.hpp (not visible to clients)
#include "project/example.hpp"
#include "project/bar.hpp"
template <class T> void check(MyClass<T> const& c) { }
// example.cpp
#include "example_impl.hpp"
// MyClass definition
typedef或template的情况下才是必需的，实现头文件也是如此;)我个人在头文件中这样做：
// class-declaration
// inline-method-declarations
我不喜欢将方法的代码与类混合在一起，因为我觉得这样很难快速查找。
我不会将所有的方法都放在头文件中。编译器通常无法内联虚拟方法，并且只会内联没有循环的小型方法（完全取决于编译器）。
在类中编写方法是有效的...但从可读性的角度来看，我不喜欢这样做。将方法放在头文件中意味着，在可能的情况下，它们会被内联。
.ipp文件（这些文件被包含在.hpp中），而.hpp则包含接口。通常在编写新类时，我会将所有代码放在类中，这样我就不必在另一个文件中查找它了。等一切都正常工作后，我将方法的主体拆分到cpp文件中，只留下hpp文件中的原型。