C++内部代码重用：编译所有内容还是共享库/动态库？

Question

一般问题：

对于非托管 C++，内部代码共享什么更好？

1. 通过共享实际源代码来重用代码？或者
2. 通过共享库/动态库（+所有头文件）来重用代码

无论是哪种：您减少重复代码（复制粘贴综合症）、代码膨胀的策略是什么？

---

具体示例：

以下是我们在组织中共享代码的方式：

我们通过共享实际源代码来重用代码。

我们使用 VS2008 在 Windows 上进行开发，尽管我们的项目实际上需要是跨平台的。我们有许多项目 (.vcproj) 已提交到存储库；有些可能有自己的存储库，有些可能是存储库的一部分。对于每个可交付的解决方案 (.sln)（例如，我们交付给客户的东西），它将从存储库中 svn:externals 所有必要的项目 (.vcproj) 来组装“最终”产品。

这工作得很好，但我很担心最终每个解决方案的代码大小可能会变得相当大（现在我们的总代码大小约为 75K SLOC）。

另外需要注意的一件事是我们阻止所有传递依赖。也就是说，不是实际解决方案 (.sln) 的每个项目 (.vcproj) 都不允许 svn:externals 任何其他项目甚至（如果它依赖于该项目）。这是因为您可能有 2 个项目 (.vcproj)，它们可能依赖于相同的库（即 Boost）或项目 (.vcproj)，因此当您将两个项目 svn:externals 放入单个解决方案时，svn:externals 会执行两次。因此，我们仔细记录每个项目的所有依赖项，并由创建解决方案 (.sln) 的人员来确保所有依赖项（包括传递性）都是 svn:externals 作为解决方案的一部分。

如果我们通过使用 .lib 、 .dll 来重用代码，这显然会减少每个解决方案的代码大小，并消除上面提到的适用的传递依赖（例外情况是，例如，第三个-使用 dll（如 Intel TBB 和默认 Qt）的第三方库/框架）

---

附录：（如果您愿意，请阅读）

共享源代码的另一个动机可能可以通过 博士。图形用户界面：

最重要的是，C++ 使之变得简单的是 不创建可重用的二进制文件 成分;相反，C++ 做到了 相对容易重用源代码。 请注意，大多数主要的 C++ 库都是 以源代码形式提供，未编译 形式。很多时候有必要 查看该来源以便 从对象正确继承——并且 这太容易了（并且经常 必要）依赖实施 原始库的详细信息 你重复使用它。好像这还不错 足够了，它常常很诱人（或者 必要）修改原来的 获取并进行私人构建 图书馆。 （有多少私人建筑 MFC有吗？世界永远不会 知道 。 。 .)

也许这就是为什么当您查看像 Intel Math Kernel 库这样的库时，在它们的“lib”文件夹中，每个 Visual Studio 版本都有“vc7”、“vc8”、“vc9”。可怕的东西。

或者这个断言怎么样：

C++ 是出了名的不包容 当谈到插件时。 C++ 是 极其特定于平台并且 编译器特定的。 C++ 标准 未指定应用程序二进制文件 接口（ABI），意思是C++ 来自不同编译器的库或 甚至同一个版本的不同版本 编译器不兼容。添加到那个 事实上 C++ 没有这个概念 动态加载和各个平台 提供自己的解决方案（不兼容 与其他人）然后你就明白了。

对于上述说法，您有何看法？像 Java 或 .NET 这样的东西会面临这类问题吗？例如，如果我从 Netbeans 生成一个 JAR 文件，如果我将其导入 IntelliJ，只要我确保两者都具有兼容的 JRE/JDK，它会工作吗？

Answer 1

人们似乎认为 C 指定了 ABI。事实并非如此，而且我也不知道有任何标准化编译语言可以做到这一点。为了回答你的主要问题，使用库当然是可行的方法 - 我无法想象做任何其他事情。

Answer 2

共享源代码的一个很好的理由是：模板是 C++ 的最佳功能之一，因为它们是一种解决静态类型刚性的优雅方法，但本质上是源代码级构造。如果您专注于二进制级接口而不是源代码级接口，那么您对模板的使用将会受到限制。

Answer 3

我们也这样做。如果您需要在不同平台、构建环境上使用共享代码，或者即使您需要不同的构建选项（例如静态与动态链接到 C 运行时、不同的结构打包设置等），尝试使用二进制文件可能是一个真正的问题。我

通常将项目设置为尽可能多地按需构建，即使使用 zlib 和 libpng 等第三方代码也是如此。对于那些必须单独构建的东西，例如 Boost，我通常必须为所需的各种设置组合（调试/发布、VS7.1/VS9、静态/动态）构建 4 或 8 组不同的二进制文件，并管理二进制文件以及源代码管理中的调试信息文件。

当然，如果共享代码的每个人都在同一平台上使用相同的工具和相同的选项，那么情况就不同了。

Answer 4

我从未将共享库视为将旧项目中的代码重用到新项目中的一种方式。我一直认为这更多的是在几乎同时开发的不同应用程序之间共享一个库，以最大限度地减少膨胀。

就复制粘贴综合症而言，如果我将其复制并粘贴到多个位置，则它需要有自己的功能。这与库是否共享无关。

当我们重用旧项目中的代码时，我们总是将其作为源代码引入。总有一些东西需要调整，调整特定于项目的版本通常比调整可能会破坏先前项目的共享版本更安全。返回并修复之前的项目是不可能的，因为 1) 它已经工作（并发货），2) 不再提供资金，3) 所需的测试硬件可能不再可用。

例如，我们有一个通信库，它有一个 API，用于通过套接字、管道等发送“消息”（带有消息 ID 的数据块）：

void Foo:Send(unsigned messageID, const void* buffer, size_t bufSize);

但在后来的项目中，我们需要优化：需要消息由内存不同部分中的多个数据块连接在一起组成，我们不能（也不想，无论如何）首先进行指针数学来创建“组装”形式的数据，并且将各个部分一起复制到统一缓冲区的过程花费了太长时间。因此我们添加了一个新的 API：

void Foo:SendMultiple(unsigned messageID, const void** buffer, size_t* bufSize);

它将缓冲区组装成消息并发送。 （基类的方法分配一个临时缓冲区，将各部分复制在一起，然后调用 Foo::Send() ；子类可以使用它作为默认值或用自己的方法覆盖它，例如发送的类套接字上的消息只需为每个缓冲区调用 send()，从而消除大量副本。）

现在，通过这样做，我们可以选择向后移植（实际上是复制）对旧版本，但我们不需要向后移植。这为管理者提供了根据时间和资金限制的灵活性。

编辑：读完尼尔的评论后，我想到了我们需要澄清的一些事情。

在我们的代码中，我们做了很多“库”。很多。我写的一个大程序大约有 50 个。因为，对于我们和我们的构建设置来说，它们很简单。

我们使用一个可以动态自动生成 makefile 的工具，处理依赖关系和几乎所有事情。如果有任何奇怪的事情需要完成，我们会编写一个包含例外情况的文件，通常只有几行。

它的工作原理如下：该工具查找目录中看起来像源文件的所有内容，如果文件发生更改，则生成依赖项，并吐出所需的规则。然后它制定一条规则，将所有内容和 ar/ranlib 放入 libxxx.a 文件中，以目录命名。所有对象和库都放在以目标平台命名的子目录中（这使得交叉编译易于支持）。然后对每个子目录（目标文件子目录除外）重复此过程。然后，顶级目录与所有子目录的库链接到可执行文件中，并在顶级目录之后再次创建裸露的符号链接。

所以目录就是库。要在程序中使用库，请创建指向它的符号链接。无痛。因此，一切从一开始就被划分到库中。如果您想要共享库，请在目录名称上添加“.so”后缀。

要从另一个项目中提取库，我只需使用 Subversion 外部来获取所需的目录。符号链接是相对的，所以只要我不留下任何东西，它仍然有效。当我们发布时，我们将外部引用锁定到父级的特定修订版。

如果我们需要向库添加功能，我们可以执行以下操作之一。我们可以修改父项目（如果它仍然是一个活动项目并且因此可测试），告诉 Subversion 使用较新的版本并修复出现的任何错误。或者，如果扰乱父级的风险太大，我们可以克隆代码，替换外部链接。不管怎样，它对我们来说仍然像一个“图书馆”，但我不确定它是否符合图书馆的精神。

我们正在迁移到 Mercurial，它没有“外部”机制，因此我们必须首先克隆库，使用 rsync 来保持不同存储库之间的代码同步，或者强制使用公共目录结构，以便你可以从多个父母那里获得汞。最后一个选项似乎效果很好。