C ++一个头多个源 [英] C++ One Header Multiple Sources

问题描述

我有一个大类 Foo ¹ ：

  class Foo {
 public：
 void apples1（）; 
 void apples2（）; 
 void apples3（）; 
 
 void oranges1（）; 
 void oranges2（）; 
 void oranges3（）; 
 
  

拆分类不是一个选项 ² ，但是 foo.cpp 文件增长得相当大。在 foo.h 中保留类的定义并将函数的实现拆分为 foo_apples.cpp 是否存在主要设计缺陷c $ c>和 foo_oranges.cpp 。

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

---

¹ 大 ，而不是机器生成的。

² 为什么？那么， apples 和 oranges 实际上是一些对图进行操作的算法类别，但它们之间的使用相当广泛。他们可以分开，但由于工作的研究性质，我不断重新布置每种算法的工作方式，而我发现的方式并不（在早期阶段）与经典的OOP原则很好地结合在一起。

解决方案

是否存在任何主要的设计缺陷，以保持foo.h中类的定义并将实现函数转换为foo_apples.cpp和foo_oranges.cpp。

选择nits：是否存在主要的设计缺陷来保留声明，并将方法的定义分割为foo_apples.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：

  #includeDEPENDENCIES.hpp
 #includeFoo.static.exported.hpp/ *如果需要的话* / 
 #includeFoo.private.exported.hpp/ *如果需要* / 
 #includeFoo.apples.exported.hpp
 #includeFoo.oranges.exported.hpp
 
 / *此处没有定义* / 
  

您可以根据需要轻松调整这些文件的分配方式。如果您使用c ++约定编写程序，那么跨越大型TU几乎不会发生冲突。如果你像C程序员一样编写（大量的全局变量，预处理器滥用，低警告级别和免费声明），那么这种方法将暴露很多你可能不会去纠正的问题。

I have a large class Foo¹:

class Foo {
public:
    void apples1();
    void apples2();
    void apples3();

    void oranges1();
    void oranges2();
    void oranges3();
}

Splitting the class is not an option², but the foo.cpp file has grown rather large. Are there any major design flaws to keeping the definition of the class in foo.h and splitting the implementation of the functions into foo_apples.cpp and foo_oranges.cpp.

The goal here is purely readability and organization for myself and other developers working on the system that includes this class.

---

¹"Large" means some 4000 lines, not machine-generated.
²Why? Well, apples and oranges are actually categories of algorithms that operate on graphs but use each other quite extensively. They can be separated but due to the research nature of the work, I'm constantly rewiring the way each algorithm works which I found for me does not (in the early stage) jive well with the classic OOP principles.

解决方案

Are there any major design flaws to keeping the definition of the class in foo.h and splitting the implementation of the functions into foo_apples.cpp and foo_oranges.cpp.

to pick nits: Are there any major design flaws to keeping the declaration of the class in foo.h and splitting the definitions of the methods into foo_apples.cpp and foo_oranges.cpp.

1) apples and oranges may use the same private programs. an example of this would be implementation found in an anonymous namespace.

in that case, one requirement would be to ensure your static data is not multiply defined. inline functions are not really a problem if they do not use static data (although their definitions may be multiply exported).

to overcome those problems, you may then be inclined to utilise storage in the class -- which could introduce dependencies by increasing of data/types which would have otherwise been hidden. in either event, it can increase complexity or force you to write your program differently.

2) it increases complexity of static initialization.

3) it increases compile times

the alternative i use (which btw many devs detest) in really large programs is to create a collection of exported local headers. these headers are visible only to the package/library. in your example, it can be illustrated by creating the following headers: Foo.static.exported.hpp (if needed) + Foo.private.exported.hpp (if needed) + Foo.apples.exported.hpp + Foo.oranges.exported.hpp.

then you would write Foo.cpp like so:

#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 */

you can easily adjust how those files are divided based on your needs. if you write your programs using c++ conventions, there are rarely collisions across huge TUs. if you write like a C programmer (lots of globals, preprocessor abuse, low warning levels and free declarations), then this approach will expose a lot of issues you probably won't care to correct.

这篇关于C ++一个头多个源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！