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

对于非托管C,内部代码共享有什么好处？

>通过共享实际源代码重用代码？要么
>通过共享库/动态库(所有头@L_616_3@)重用代码

无论它是什么：减少重复代码(复制粘贴综合症)的策略是什么,代码膨胀？

具体例子：

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

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

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

这很好用,但我最担心的是每个解决方案的代码大小最终会变得非常庞大(现在我们的总代码大小约为75K SLOC).

还有一点需要注意的是,我们会阻止所有传递依赖.也就是说,不是实际解决方案(.sln)的每个项目(.vcproj)都不允许svn：externals任何其他项目,即使它依赖于它.这是因为你可能有2个项目(.vcproj)可能依赖于同一个库(即Boost)或项目(.vcproj),因此当你svn：将两个项目外部集成到一个解决方案中时,svn：externals会做两次.因此,我们仔细记录每个项目的所有依赖项,并由创建解决方案(.sln)的人员确保所有依赖项(包括传递)都是svn：externals作为解决方案的一部分.

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

附录:(如果你愿意,请阅读)

共享源代码的另一个动机可能最好总结为Dr. GUI：

也许这就是为什么当你查看像Intel Math Kernel库这样的库时,在他们的“lib”@L_616_3@夹中,每个Visual studio版本都有“vc7”,“vc8”,“vc9”.可怕的东西.

或者this断言怎么样：

你对上述断言的看法是什么？像Java或.NET这样的问题会面临这些问题吗？例如如果我从Netbeans生成一个JAR@L_616_3@,只要我确保它们都兼容JRE / JDK,它会导入IntelliJ吗？