将C ++定义放在头文件中是一种好习惯吗？

我个人使用C ++的风格总是将类声明放在include文件中，并将定义放在.cpp文件中，这与Loki对C ++头文件代码分离的回答中所规定的非常相似。诚然，我喜欢这种样式的部分原因可能与我过去对Modula-2和Ada进行编码所花费的时间有关，这两种方式在规范文件和主体文件方面都有相似的方案。

我有一个同事，比我更懂C ++，他坚持认为所有C ++声明都应尽可能在头文件中包括这些定义。他并不是说这是一种有效的替代样式，甚至不是一种更好的样式，而是这是每个人现在都在使用C ++的新的普遍接受的样式。

我不像以前那样虚弱，所以我真的不急于爬上他的这个潮流，直到我看到更多的人和他在一起。那么这个成语到底有多普遍？

只是为了给出一些答案的结构：现在是The Way，很常见，有点常见，不常见或被bug淘汰吗？

您的同事是错误的，通常的方法是一直将代码放在.cpp文件（或您喜欢的任何扩展名）中，并将声明放在标头中。

有时将代码放入标头中有一些好处，这可以使编译器进行更巧妙的内联。但是同时，由于每次编译器都必须处理所有代码时，它可能会破坏编译时间。

最后，当所有代码都是头文件时，具有循环对象关系（有时是理想的）通常很烦人。

底线，你是对的，他是错的。

编辑：我一直在想你的问题。在一种情况下，他说的是真的。模板。许多新的“现代”库（例如boost）都大量使用模板，并且常常是“仅标头”。但是，仅应在处理模板时执行此操作，因为这是处理模板时的唯一方法。

编辑：有些人想要更多的说明，这是编写“仅标头”代码的缺点：

如果四处搜寻，您会发现很多人都在尝试寻找一种方法来减少处理boost的编译时间。例如：如何使用Boost Asio减少编译时间，这将看到包含boost的单个1K文件的14s编译。14s似乎没有“爆炸性”，但肯定比典型的要长得多，并且累积起来很快。处理大型项目时。仅标头的库确实以相当可衡量的方式影响编译时间。我们只是容忍它，因为升压非常有用。

此外，还有很多事情不能仅在标头中完成（即使boost具有某些线程，文件系统等某些部分都需要链接的库）。一个主要的例子是，您不能在仅标头的lib中拥有简单的全局对象（除非您诉诸于单例的可憎），否则会遇到多个定义错误。注意： C ++ 17的内联变量将使该特定示例在将来可行。

最后一点，当使用boost作为仅标头代码的示例时，经常会遗漏大量细节。

Boost是库，而不是用户级代码。因此它不会经常改变。在用户代码中，如果将所有内容放在标头中，则每个小的更改都将导致您不得不重新编译整个项目。这是巨大的时间浪费（对于不从编译到编译不变的库而言，情况并非如此）。当您在标头/源和更好之间进行拆分时，使用前向声明减少包含，可以在一整天的总和中节省重新编译的时间。

C ++编码人员在The Way上达成共识的那天，羔羊将与狮子同卧，巴勒斯坦人将拥抱以色列人，猫和狗将被允许结婚。

此时，.h和.cpp文件之间的分隔几乎是任意的，这是编译器优化的痕迹。在我看来，声明属于标题，而定义属于实现文件。但是，这只是习惯，而不是宗教信仰。

标头中的代码通常不是一个好主意，因为当您更改实际代码而不是声明时，它会强制重新编译所有包含标头的文件。由于您需要解析每个包含标头的文件中的代码，因此也会减慢编译速度。

在头文件中包含代码的原因是，通常需要关键字inline正常工作以及使用在其他cpp文件中实例化的模板时。

可能会通知您的同事的想法是，大多数C ++代码应模板化以实现最大的可用性。而且，如果已将其模板化，则所有内容都必须位于头文件中，以便客户端代码可以看到并实例化它。如果对Boost和STL足够好，那么对我们也足够。

我不同意这种观点，但可能是它的来历。

我认为您的同事很聪明，您也是正确的。

我发现将所有内容放入标头的有用之处在于：

1. 无需编写和同步标题和源。

2. 结构是简单的，没有循环依赖关系会迫使编码器形成“更好”的结构。

3. 可移植，易于嵌入到新项目中。

我确实同意编译时间问题，但是我认为我们应该注意到：

1. 源文件的更改很可能会更改头文件，从而导致重新编译整个项目。

2. 编译速度比以前快得多。而且，如果您要长时间长时间构建项目，则可能表明您的项目设计存在缺陷。将任务分为不同的项目和模块可以避免此问题。

最后，就我个人而言，我只想支持您的同事。

通常，我会将一些琐碎的成员函数放入头文件中，以使它们内联。但是要将整个代码放在那里，只是为了与模板保持一致？简直是疯了。

记住：愚蠢的一致性是小头脑的妖精。

正如Tuomas所说，您的标头应该最小。为了完整起见，我将扩展一点。

我个人在C++项目中使用了4种类型的文件：

• 上市：
• 转发头：如果是模板等，此文件将获取将出现在头中的转发声明。
• 标头：此文件包含转发标头（如果有），并声明我希望公开的所有内容（并定义了类...）
• 私人的：
• 专用标头：此文件是为实现保留的标头，它包含标头并声明辅助函数/结构（例如对于Pimpl或谓词）。如有必要，跳过。
• 源文件：它包含私有头（如果没有私有头，则包含头）并定义所有内容（非模板...）

此外，我将其与另一条规则结合在一起：不要定义可以转发声明的内容。尽管我在那里当然很合理（在任何地方使用Pimpl都很麻烦）。

这意味着#include我可以在头文件中使用前向声明而不是指令。

最后，我还使用可见性规则：我尽可能限制符号的范围，以免它们污染外部范围。

放在一起：

// 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等特点，是实现头;）

为了增加乐趣，您可以添加.ipp包含模板实现（包含在中.hpp）而.hpp包含接口的文件。

除了模板化的代码（取决于项目，它可以是文件的多数或少数）之外，还有普通的代码，此处最好将声明和定义分开。在需要的地方还提供前向声明-这可能会影响编译时间。

通常，在编写新类时，我会将所有代码放入该类中，因此不必在另一个文件中查找它。.一切正常之后，我将方法的主体分解为cpp文件。 ，将原型保留在hpp文件中。

如果这种新方法确实是The Way，那么我们的项目可能会朝着不同的方向发展。

因为我们试图避免标题中所有不必要的东西。这包括避免头级联。标头中的代码可能需要包含一些其他标头，这将需要另一个标头，依此类推。如果我们被迫使用模板，我们将尽量避免在模板头上乱扔标题。

同样，在适用时，我们使用“不透明指针”模式。

通过这些实践，我们可以比大多数同行更快地进行构建。是的...更改代码或类成员不会导致大量重建。

我个人在头文件中执行此操作：

// class-declaration

// inline-method-declarations

我不喜欢将方法的代码与类混在一起，因为我发现快速查找内容很麻烦。

我不会将所有方法放在头文件中。编译器将（通常）无法内联虚拟方法，并且（可能）仅内联小型方法而没有循环（完全取决于编译器）。

在类中执行方法是有效的……但是从可读的角度来看，我不喜欢它。将方法放在标头中确实意味着，如果可能，它们将被内联。

恕我直言，他只有在做模板和/或元编程时才有优点。已经有很多原因提到您将头文件限制为仅声明。它们就是...标题。如果要包含代码，则将其编译为库并链接起来。

我将所有实现都放在类定义之外。我想从类定义中删除doxygen注释。

我认为将所有函数定义放入头文件中绝对是荒谬的。为什么？因为头文件用作类的PUBLIC接口。这是“黑匣子”的外部。

当需要查看一个类以引用如何使用它时，应查看头文件。头文件应提供其功能的列表（注释以描述如何使用每个函数的详细信息），并且应包括成员变量的列表。它不应该包括如何实现每个单独的功能，因为那是一堆不必要的信息，只会使头文件杂乱无章。

这不是真的取决于系统的复杂性以及内部惯例吗？

目前，我正在开发一个极其复杂的神经网络模拟器，并且我期望使用的公认样式是：

classname.h中的类定义classnameCode.h中的
类代码classname.cpp中的
可执行代码

这将用户构建的仿真与开发人员构建的基类分离开来，并且在这种情况下效果最佳。

但是，我很惊讶地看到人们在图形应用程序或任何其他旨在不为用户提供代码库的应用程序中执行此操作。

模板代码应仅在标题中。除此之外，除内联外，所有定义均应使用.cpp。最好的说法是遵循相同规则的std库实现。您不会不同意std lib开发人员对此的看法。

我认为您的同事是对的，只要他不参与在标头中编写可执行代码的过程即可。我认为，正确的平衡点是遵循GNAT Ada指示的路径，在该路径中.ads文件为用户及其子级用户提供了一个非常完善的包接口定义。

顺便说一下，Ted，您是否在这个论坛上浏览了有关Ada绑定到您几年前编写的CLIPS库的最新问题，现在该问题不再可用（相关网页现已关闭）。即使是旧的Clips版本，此绑定对于愿意在Ada 2012程序中使用CLIPS推理引擎的人来说也是一个很好的入门示例。