C++ - 使用#include 而不是#include 有好处吗？

Question

我知道标准库使用 include with .h 用于旧的 C 库，而 include without .h 用于最新的库。但是，对于自己的类(class)来说，更好的做法是什么？

在我工作的地方，我们总是有一个 include 文件夹，每个类有两个文件:classname.h 和 ClassName。 ClassName 包含 classname.h，classname.h 包含真正的类头文件。要包含一个类，您然后使用

#include <ClassName>

Qt 就是这样做的，我很确定 Qt 是他们开始在我的公司这样做的原因。但这有什么好处吗？

缺点很明显，我认为:

• 要为新类创建另一个文件(我们使用 bash 脚本来创建，但仍然如此)
• 每个类(class)多管理一个文件
• 通过 IDE 重命名文件/类时，您通常必须手动调整 ClassName 文件(即使 Qt Creator 也做不到)
• 除了 std 库和 Qt，我从未在任何地方见过这种风格

你使用这种风格吗？如果是这样，为什么？它的论据是什么？还有更多反对意见吗？

Answer 1

首先，我要编一个术语，称之为“特定类包含文件”或“CSIF”。这些文件不以 .h 结尾，即使它们像标题一样使用，因此是“包含文件”部分。既然我要继续提到这个东西，我不妨也给它一个首字母缩略词。

这是如何在Qt中实现的

Qt 有一个“头”文件，每个定义的 Qt 没有扩展名 class或 struct ，这个答案被称为 CSIF。 CSIF 直接进入 \include带有普通头文件的路径，但是如果你打开一个头文件，它们都会做同样的事情。让我们从 QtWidgets 中的包含文件开始，尤其是与 QStyleOption 相关的那些:

\include
    ...
    QStyleOption
    qstyleoption.h
    QStyleOptionButton
    QStyleOptionComboBox
    ...

如果你打开其中一个 QStyleOption -相关的CSIF，都包含一行代码:

#include "qstyleoption.h"

并且在 qstyleoption.h :

#include "../../src/widgets/styles/qstyleoption.h"

CSIF 所做的就是 #include源代码树中以其命名的类的正确 header 。 它在类的实际定义和 #include 之间创建了一个抽象级别声明需要使用它。结果，这段代码:

//In some .cpp file somewhere
#include <QStyleOptionButton>
#include <QStyleOptionComboBox>

包含相同的头文件(当然，由守卫保护)，但使用 Qt 的开发人员不需要知道这一点。开发人员只关心他/她正在使用一个类，并且他/她想确定该类是否可用。 我不知道这是不是原来的逻辑，但就是这样。

具体问题的答案

<强>1。你用这种风格吗？如果是，为什么？
是的，但只是因为我正在从事的项目模拟了 Qt 库的风格，所以 Qt 开发人员可以在 Qt 旁边舒适地使用它。否则，[插入大量咒骂]。

<强>2。它的论据是什么？
我所知道的唯一好的论据是上面的，关于 Qt 如何使用它来抽象类及其定义的位置。作为 Qt 的用户，确保包含正确的头文件是轻而易举的事。如果我使用类 QFoo ，我包括:<QFoo> .简单。

<强>3。还有更多的反对意见吗？
正如您在问题中指出的那样，有很多反对意见。

• 它使重构变得更加困难。
• 只有在开发库时它才真正有用。
• 只有当您的库具有 API 稳定性保证并且相当成熟时，才值得您花时间，因为它会使重构变得更加困难。
• 这意味着您的库导出的每个类都必须有一个 CSIF，很容易漏掉一个。

我相信其他人可以想出更多 CSIF 让生活变得困难的例子。总之，在做出决定之前，必须权衡它在您的库中增加的刚性与最终开发人员的好处之间的平衡。

至于您的工作场所如何使用它……我只是耸耸肩。也许有人在不明白为什么的情况下复制了 Qt 样式？