c++ - 什么时候把一个小类分成头文件和cpp文件？

Question

我知道之前已经回答过类似的问题，但我搜索了 stackoverflow(等)，但没有找到关于如何处理在程序中实例化并仅使用一次的小类的明确想法。仍然在单独的文件中声明和实现真的很重要吗？

举个例子:

// timer.hpp

#pragma once
#include "presets.h" // includes #defines for u64 -> uint64_t, etc

class Timer {
    public:
        Timer() {}
        Timer(u64 elt) : elt_(elt) {}

        void startTiming() { if (NOT running_){ running_ = true;  sTime_ = GetTickCount64(); }};
        void stopTiming() { if (running_)     { running_ = false; eTime_ = GetTickCount64(); elt_ += (eTime_ - sTime_); sTime_ = eTime_; }}

        u64 getElapsed() { if (NOT running_) return elt_; eTime_ = GetTickCount64(); return elt_ + eTime_ - sTime_; }
    private:
        bool running_ = true;
        u64 elt_ = 0, eTime_ = 0, sTime_ = GetTickCount64();
};

我读过的所有内容都坚持将声明和实现放在单独的文件中，但是将这样一个简单的类拆分为 .h 文件和 .cpp 文件似乎很荒谬。它很少被改变并且只被实例化一次。

我还有一些其他类，更大一些，而且我目前在 2 个文件中只使用了一次。假设一个类在程序中只实例化一次，我的问题是:

1. 将声明和实现放在一个小的位置是否合理类在一个文件中？如果不是，为什么不呢？
2. 在更好地分离之前，一个类需要多大分为 2 个文件？

我知道这里已经存在非常相似的问题，但我还没有阅读任何对上述问题给出明确答案的文章。

Answer 1

1. Is it reasonable to put declaration and implementation of a small class in a single file?

是的，将一个小类的声明和实现放在一个文件中是合理的。

If not, why not?

因为如果函数定义被修改，那么所有依赖类定义的翻译单元都需要重新编译——或者更确切地说，所有包含该定义的翻译单元都需要重新编译。这包括所有依赖类的类，因为它们必须包含定义，但也包括无偿包含定义的类。

2. How large does a class need to be before it's better to separate into 2 files?

没有硬性限制。它取决于许多变量，并且在很大程度上受个人偏好的影响。

有些人将所有成员函数定义放在每个类的一个翻译单元中，因为这是他们知道事情如何完成的方式，或者因为他们有必须遵循的编码标准。

其他人发誓，如果没有通过在 header 中内联定义所有函数从而使整个程序只有一个翻译单元所允许的优化可能性，他们就无法生存。这也具有从头开始减少编译时间的效果，但也会导致整个项目在发生任何更改时重新构建。

但是没有必要教条地遵循这两种路径中的任何一种，而且它们都不一定是最优的 - 两者都有缺点和优点。因此，一个好的选择可能是介于这些路径之间。但正如我上面所说，选择取决于许多变量，因此最好使用快速启发式而不是全面分析。如果您发现推理合适，可以遵循以下几点:

• 如果函数定义为空，则非常适合内联定义。
• 如果函数或类是模板，那么您必须内联定义它 - 您别无选择(除非您可以限制可能的模板实例化的数量)。
• 如果函数的定义依赖于类的定义否则不依赖的定义。如果您定义内联函数，则会导致依赖关系传播。在这种情况下，最好不要定义内联函数。
• 如果您习惯于极少修改函数的定义，并且该定义在许多翻译单元中使用，那么最好不要内联定义函数，否则您可能会发现你自己一次又一次地重新编译大部分项目。如果项目很小并因此可以快速完整编译，那么这种启发式并不重要。此外，使用一个类的地方的数量通常很难跟踪，因此假设最坏的情况通常更简单。
• 如果您分析程序并发现某个特定函数每秒被调用一百万次，那么它是内联定义的一个很好的候选者，可以利用内联扩展优化。请注意，即使函数是在单独的翻译单元中定义的，使用链接时间优化也可能允许内联扩展。
• 如果一个函数编译起来很慢，那么最好不要内联定义它。现在，要知道哪些函数编译速度慢并不容易，因此您还需要一组启发式方法。这里有一些，如果你觉得推理合适，你可以遵循:
  • 较长的函数定义通常比较短的函数定义编译速度慢。
  • 实例化模板的函数有时编译起来会很慢。

Assuming a class is only instantiated once in the program

实例化的数量与选择无关——除了内联构造函数在这种情况下对性能可能并不重要。

---

附言

虽然它非常便携，#pragma once是非标准的。我不是说你应该摆脱它；这只是需要注意的事情。

GetTickCount64是特定于系统且不可移植的。 C++ 在 <chrono> 中有一个标准时钟 API标题。