siv*_*udh 7 c++ code-reuse unmanaged
对于非托管C++,哪些内部代码共享更好？
无论它是什么:减少重复代码(复制粘贴综合症)的策略是什么,代码膨胀？
以下是我们在组织中共享代码的方式:
我们通过共享实际的源代码来重用代码.
我们使用VS2008在Windows上开发,尽管我们的项目实际上需要跨平台.我们有许多项目(.vcproj)已提交到存储库; 有些可能有自己的存储库,有些可能是存储库的一部分.对于每个可交付的解决方案(.sln)(例如我们交付给客户的东西),它将svn:从存储库中外部所有必要的项目(.vcproj)来组装"最终"产品.
这很好用,但我很担心每个解决方案的代码大小最终会变得非常大(现在我们的总代码大小约为75K SLOC).
还有一点需要注意,我们会阻止所有传递依赖.也就是说,不是实际解决方案(.sln)的每个项目(.vcproj)都不允许svn:externals任何其他项目,即使它依赖于它.这是因为您可能有2个项目(.vcproj)可能依赖于同一个库(即Boost)或项目(.vcproj),因此当您将两个项目外部转换为单个解决方案时,svn:externals将执行两次.因此,我们会仔细记录每个项目的所有依赖项,并由创建解决方案(.sln)的人员来确保所有依赖项(包括传递)都是svn:externals作为解决方案的一部分.
如果我们通过使用.lib,.dll来重用代码,这显然会减少每个解决方案的代码大小,并在适用的情况下消除上面提到的传递依赖性(例外,例如,使用的第三方库/框架) dll喜欢Intel TBB和默认Qt)
附录:(如果您愿意,请阅读)
GUI博士最好总结共享源代码的另一个动机:
最重要的是,C++简单易用的不是创建可重用的二进制组件; 相反,C++使得重用源代码变得相对容易.请注意,大多数主要的C++库都是以源代码形式提供的,而不是编译形式.通常需要查看该源以便从对象中正确继承 - 并且在重用它时依赖原始库的实现细节太简单(并且经常是必要的).好像这还不够糟糕,修改原始源并进行库的私有构建通常很诱人(或必要).(MFC有多少私人构建？世界永远不会知道......)
也许这就是为什么当你查看像Intel Math Kernel库这样的库时,在他们的"lib"文件夹中,每个Visual Studio版本都有"vc7","vc8","vc9".可怕的东西.
或者这个断言怎么样:
众所周知,C++在插件方面是不适应的.C++是特定于平台和特定于编译器的.C++标准没有指定应用程序二进制接口(ABI),这意味着来自不同编译器的C++库甚至同一编译器的不同版本是不兼容的.除此之外,C++没有动态加载的概念,每个平台都提供自己的解决方案(与其他平台不兼容),您就可以了解情况.
你对上述断言的看法是什么？像Java或.NET这样的问题会遇到这些问题吗？例如,如果我从Netbeans生成一个JAR文件,只要我确保它们都兼容JRE/JDK,它是否可以导入IntelliJ？