C语言中常见的代码重用策略是什么

上下文：C语言，8位微处理器

我们已经确定了可以在项目（产品）之间重用的组件。但我找不到处理可重用组件的最佳基础结构

到目前为止，我发现了两种可能性：

• 静态库
• subversion中的共享文件

---

共享库和共享源代码都允许您在项目之间共享公共代码。库提供了两种备选方案中更好的一种，因此如果您的平台上有可用的话，您应该使用它们。这使您可以保护库的源代码不受意外修改的影响，如果源代码管理中的代码在本地更改，则可能会发生这种情况

---

通过库共享代码的唯一问题可能是嵌入式工具链中的某些工具（例如，连接到电路内模拟器的调试器）不支持对库代码进行源代码级调试。在这种情况下，通过源代码重用代码是可以接受的。如果可能的话，您应该通过文件系统访问控制来保护源代码不被修改。

如果您有可重用的组件，那么可以使用库

它更易于维护，并且有一个清晰的界面。它也更容易合并到新项目中

您可以轻松地对库代码进行单独的单元测试

复制和粘贴代码的风险较小

程序员更清楚地意识到，当他们必须从库中使用这些代码时，它们是共享的

---

对于库方法，已经提出了一些很好的论据

---

但是，每次构建依赖项目时，至少有一个很好的理由支持重新构建（可能来自同一个源存储库），那就是能够将目标-项目-或开发阶段-唯一的编译设置应用于所有代码，包括共享部分

在我的公司，我们同时使用了两种方法：

• 我们进行两次签出：一次是项目签出，另一次是图书馆签出
• 当项目需要编译时（通过

  Makefile

  ），我们首先编译库
• 然后链接该库，就好像它是一个仅限二进制的库一样
• 当我们发布一个项目时，我们检查其他项目是否仍然根据新库编译
• 当我们发布一个项目时，我们会在项目中标记库

通过这种方式，您可以两全其美：

• 共享公共代码：所有项目都从错误修复和改进中受益
• 源代码始终完全可用于理解和调试
• 源代码可用性鼓励库维护（修复、改进和实验）
• 库边界采用了一种更像API的方法：更清晰的接口和项目嵌入
• 您可以将编译时标志传递给库以构建不同的样式
• 如果需要，您可以随时返回时间，而不会遇到库与项目不匹配的麻烦
• 如果你赶时间，你可以推迟图书馆的检查

---

这种方法的唯一缺点是开发人员不知道他们在做什么。如果他们修改库，他们应该知道更改将影响所有项目。但是您已经在使用版本控制系统，如果您使用分支机构，并且团队内部的沟通良好，那么应该不会有任何问题。

海报所说的是共享单个源文件，而不是共享库。；）@Devolus OP在问题中提到了静态库，因此我认为库是可以的。实际上共享源模块，如某些线程中所示。例如，使用库时会增加内存占用的开销吗？@ojota84理论上，如果不以正确的粒度对库进行分区，而且您的工具还不足以消除未使用的代码。我会用您的特定工具尝试这两种方法，看看可执行代码的大小是否有差异。svn aproach有什么优点吗？我见过很多问题，他们在哪里使用SVN来重用代码，例如，我在一家公司工作过，他们使用了类似的方法，这很可怕，因为代码被分成了不同的项目。这意味着我们必须在不同的副本中一次又一次地修复bug。我真的不认为这样做有什么意义。库是一个干净的分离，如果库真的是一个库，没有来回的依赖关系，那么在我看来它是最干净和最好的选择。调试并不是一个原因，因为您可以访问源代码。在这里，源代码级共享和对象级共享之间的明显区别并没有那么大。也就是说，问哪种备选方案最好的问题通常不适合SO格式。确切地说，这些构建选项（预编译逻辑）是C的一个重要特性。但是我们应该使用静态库来消除它们，还是有一些架构策略可以给我们您描述的这些功能。谢谢，这对我帮助很大。我只是想知道你是如何管理这些库的发布的？在发布的那一刻，你给它贴上标签了吗？或者你生成了一个存储在某处的二进制文件？在你的文章中我还遗漏了一些东西。Devolus在第1点和第2点提到了一些非常重要的事情。你是如何解决这些问题的？我发现了一篇有趣的论文，其中描述了用于分离预处理器关注点的方法。他们提到了一些有趣的工具，比如