什么是用C通用代码复用策略
语境：C语言，8位微处理器什么是用C通用代码复用策略
我们已经确定了可以在项目（产品）之间重复使用的组件。但我无法找到哪个处理可重用组件的最佳基础架构。
两种可能性，我发现到现在：在颠覆
- 静态库
- 共享文件
在我的公司，我们使用在同一时间两种方法：
- 我们做两次检出：一个项目，其他为库。
- 当项目需要编译（通过
Makefile），我们首先编译库。 - 然后链接该库，就好像它是一个只有二进制文件的库。
- 当我们发布一个项目时，我们检查其他项目是否仍然针对新库进行编译。
- 当我们发布一个项目时，我们将该库与该项目一起标记。
这样你得到两全其美：
- 公共代码共享：所有项目从错误修复和改进中获益
- 源代码始终是完全可以理解和调试
- 源代码的可用性鼓励库维护（固定装置，改进和实验）
- 图书馆界判处更API样的方法：更清晰的界面和项目嵌入
- 你可以通过编译时间标志到图书馆建立一个不同的口味
- 如果需要的话，而不库VS-项目不匹配，你可以随时回到过去的麻烦
- ，如果你是在赶时间，你可以推迟图书馆检查。
这种方法的唯一缺点是开发人员不知道他们在做什么。如果他们修改图书馆，他们应该知道这一变化将影响到所有项目。但是，您已经在使用版本控制系统，并且如果您使用分支机构并且团队内部的沟通很好，那么应该没有任何问题。
谢谢，它帮助我很多。我只想知道你如何管理图书馆的版本？在发布的那一刻你会标记它？或者您生成存储在某处的二进制文件？ –
在你的问题中还有其他的东西我想念你。 Devolus在第1点和第2点提到了一些非常重要的事情。你是如何解决这些问题的？ –
我发现了一篇有趣的论文，他们描述了与预处理器http://wwwiti.cs.uni-magdeburg.de/iti_db/publikationen/ps/10/diss_kaestner.pdf分离问题的方法。他们提到了一些有趣的工具，如http://wwwiti.cs.uni-magdeburg.de/iti_db/research/cide/ –
共享库和共享源代码，让大家分享项目中的公共代码。图书馆提供了更好的两种选择，所以你应该在平台上使用它们。这样可以防止无意中修改库的来源，如果源代码管理的代码在本地发生更改，则可能会发生这种情况。
与共享代码通过库的唯一问题可能是缺乏用于通过在嵌入式工具链的一些工具的库代码源代码级调试支持（例如附连到仿真器的调试器）。在这种情况下，通过源代码重用代码可能是可以接受的。如果可能，您应该通过文件系统访问控制来防止修改源。
海报正在讨论共享单个源文件，而不是共享库。 ;） – Devolus
@Devolus OP提到了问题中的静态库，所以我认为库是可以的。 – dasblinkenlight
实际上共享源码模块，如某些线程所示，例如。 http://stackoverflow.com/questions/5673767/svn-common-code-with-externals?rq=1 –
如果有可重用的组件，图书馆是要走的路。
- 它更容易维护，并且您有一个清晰的界面。纳入新项目也更容易。
- 您可以轻松完成单个单元测试的库代码
- 风险较低复制和粘贴代码。
- 程序员更知道，当他们必须从库中使用这个代码是共享的。
svn aproach有一些优点吗？我看到很多问题，他们使用SVN重用代码。 http://stackoverflow.com/questions/669628/svn-best-way-to-share-common-code-across-projects –
我曾在一家公司工作过，他们使用类似的方法，这是可怕的，因为代码分成不同的项目。这意味着我们必须在不同的副本中一遍又一遍地修复错误。我真的不明白这一点。一个图书馆是一个干净的分离，如果图书馆真的是一个图书馆，没有依赖关系来回，那么它就是最干净和最好的选择。调试不是一个原因，因为你可以让源代码访问。 – Devolus
几个很好的理由已经进行了图书馆的做法。
然而，有一个为重楼（也许从相同源代码库），每次构建一个相关项目时间至少一个很好的理由，这将是应用靶项目或发展阶段 - 的能力所有代码的独特编译设置，包括共享部分。
确切地说，那些构建选项（预编译器逻辑）是C的一大特性。但是，我们应该使用静态库来摆脱它们，还是有架构策略可以为我们描述这些功能。 –
这里的明显差异 - 源代码级别共享和对象级别共享 - 并不是那么好。也就是说，询问哪种替代品最好的问题通常不适合SO格式。 –