c++一个头多个源

C++ One Header Multiple Sources

本文关键字：一个 c++      更新时间：2023-10-16

我有一个大的类Foo 1:

class Foo {
public:
    void apples1();
    void apples2();
    void apples3();
    void oranges1();
    void oranges2();
    void oranges3();
}

拆分类不是一个选项2，但是foo.cpp文件已经变得相当大了。将类的定义保留在foo.h中，将函数的实现拆分为foo_apples.cpp和foo_oranges.cpp，是否存在重大的设计缺陷?

这里的目标纯粹是为了我自己和其他开发人员在包含这个类的系统上工作的可读性和组织性。

1"Large"是指大约4000行，不是机器生成的。
2 <一口> 共舞,为什么?apples和oranges实际上是在图上操作的算法的类别，但它们之间的使用非常广泛。它们可以分开，但由于工作的研究性质，我不断地重新布线每个算法的工作方式，我发现(在早期阶段)与经典的面向对象原则不太一致。

将类的定义保留在foo.h中，并将函数的实现拆分为foo_apple .cpp和foo_oranges.cpp，是否存在重大的设计缺陷?

在foo.h中保持类的声明，并将方法的定义拆分为foo_apple .cpp和foo_oranges.cpp. ，是否存在重大的设计缺陷?

1)苹果和橘子可以使用相同的私有程序。这方面的一个例子是在匿名命名空间中找到的实现。

在这种情况下，一个要求是确保静态数据不是多重定义的。如果内联函数不使用静态数据(尽管它们的定义可以多次导出)，则它们不是真正的问题。

为了克服这些问题，你可能会倾向于利用类中的存储——这可能会通过增加原本隐藏的数据/类型来引入依赖关系。在任何一种情况下，它都可能增加复杂性或迫使您以不同的方式编写程序。

2)增加了静态初始化的复杂性。

3)增加编译时间

在真正的大型程序中，我使用的替代方法(顺便说一句，许多开发人员都讨厌)是创建一个导出的本地头文件的集合。这些头文件只对包/库可见。在您的示例中，它可以通过创建以下头来说明:Foo.static.exported.hpp(如果需要)+ Foo.private.exported.hpp(如果需要)+ Foo.apples.exported.hpp + Foo.oranges.exported.hpp。

那么Foo.cpp就写成这样:

#include "DEPENDENCIES.hpp"
#include "Foo.static.exported.hpp" /* if needed */
#include "Foo.private.exported.hpp" /* if needed */
#include "Foo.apples.exported.hpp"
#include "Foo.oranges.exported.hpp"
/* no definitions here */

您可以根据需要轻松调整这些文件的划分方式。如果您使用c++约定编写程序，那么在巨大的tu之间很少会发生冲突。如果你像一个C程序员那样编写代码(大量的全局变量、滥用预处理器、低警告级别和自由声明)，那么这种方法将暴露出许多你可能不想纠正的问题。

从技术角度来看，这样做根本没有任何惩罚，但我从未在实践中看到过这样做。这只是一个风格问题，按照这种精神，如果它能帮助您更好地阅读类，那么不使用多个源文件将对您自己造成伤害。

编辑:补充说，虽然，你的物理滚动你的源代码，像，用你的鼠标中轮?正如其他人已经提到的，IDE几乎普遍允许您右键单击函数声明，然后转到定义。即使你的IDE不是这样，你使用记事本之类的，它至少会有ctrl+f。

是的，您可以在一个头文件中定义类，并将函数实现拆分到多个源文件中。这通常不是常见的做法，但它会起作用，而且不会有开销。

如果这样做的目的只是为了提高可读性，那么这样做可能不是一个好主意，因为在多个源文件中使用类函数定义并不是很常见的做法，可能会让人感到困惑。

实际上，我不认为有任何理由将实现分开，因为其他开发人员应该处理接口，而不是实现。

另外，任何普通的IDE都提供了从函数声明跳转到函数定义的简单功能。因此，没有理由手动搜索函数实现。

相关文章：