C++图书馆组织

Question

我正在构建一个非常基础的图书馆，这是我计划发布给他人使用的第一个项目，如果他们愿意的话。因此，我想知道一些组织的“最佳实践”。可能是我的项目中是唯一的唯一的事情是，为了使它在一个项目中使用，用户将被要求延长某些抽象类，这使我对我的第一个问题：

• 很多我见过的库包含一个.a文件和一个.h文件。这是最佳做法吗？公开所有的.h文件是不是更好，以便用户可以选择包含哪些文件？如果这是做事的首选方式，那究竟是如何完成的？什么进入单一的.h文件？

我的第二个问题涉及到依赖关系。例如我目前的项目依赖于OpenGL，GLFW和GLEW。 我是否应该以某种方式将它们与我的项目一起打包，或者只是让用户有责任确保它们已安装？

编辑：有人问我的目标操作系统。我所有的依赖都是跨平台的，所以我（可能天真地）希望让我的图书馆跨平台。

感谢您的帮助！

Answer 1

这要看情况而定。如果你有一些相当复杂的功能，这些功能有很多密切相关的功能，那么一个头是正确的解决方案。

E.g.你写的一组画东西到屏幕的功能，你需要几个功能confgiure /设置环境，一些功能来定义，并在现场放置物体，几个函数做实际的绘图/加工，最后拆解，然后使用一个头文件是一个很好的计划。

在上述情况下，它也可以有一个“整体”头文件，其中包括几个小的。特别是如果你有相当大的类，把它们全部放在一个文件中会变得相当混乱。另一方面，如果您有一组处理溶解在液体中的气体的函数，另一组函数用于计算钢梁的强度/载荷能力，另一组函数用于计算摩擦力的另一组函数一个橡胶轮胎靠在路面上，那么他们可能应该拥有不同的标题 - 即使在“物理/力学图书馆”中都有可行的功能。

向您的图书馆提供第三方图书馆是一个好主意 - 是的，如果您想提供两个下载，一个是“你所有的东西，只需加水”，另一个是“裸露的图书馆”，那就是精细。但我不想花费比下载图书馆所需时间长三倍的时间，因为它还包含了您的代码正在使用的其他三个库，这些库已经在我的机器上。但是，请记录需要哪些库，以及在受支持的平台上安装它们（以及支持的平台）需要执行的操作。还有什么版本的库你已经测试 - 没有什么比“得到最新”更糟糕，只是发现某些东西需要的版本是后退两步......

（并且正如Jason C指出的那样，许可变得非常混乱一旦你有你的代码依赖，因为你的许可证，则必须与所有其他许可证兼容的几个不同的包 - 有时候这甚至不能

Answer 2

你有选择，这取决于你选择使用你的库的开发者有多方便。

至于标题，平均复杂度的库的一般方法是有一个单一的标题，开发人员可以包含它来获取他们需要的一切。一个好方法是，如果你有多个标题，创建一个与你的库名字相同的标题（不需要，只是普通的），并让它包含所有单独的标题。然后分发单个标题和单个标题。这样，您的用户可以选择#include只包含一个以获取所有内容，或者在必要时包含＃个。

E.g.在mylibrary.h：

#ifndef MYLIBRARY_H 
#define MYLIBRARY_H 

#include <mylibrary/something.h> 
#include <mylibrary/another.h> 
#include <mylibrary/lastone.h> 

#endif 

确保您的个人首部可以包含独立的（即它们＃包括他们所需要的一切），如果你想提供一个选项给开发者。

至于依赖关系，您需要使用户有责任确保它们已安装。用户正在编译他们的代码并链接到您的库，因此链接到相关库也是用户的责任。如果您将第三方依赖包与您的库封装在一起，将会产生很多风险：

1. 打破已安装依赖项的用户系统。
2. 正如Mats Petersson的答案中所提到的，迫使用户下载他们已有的依赖关系。
3. 违反第三方库的许可权利。

要做的最好的事情是清楚地记录所需的依赖关系。

为此，没有真正标准的“最佳实践”。任何理智的做法都是很好的做法。