对于非托管C,内部代码共享有什么好处？
>通过共享实际源代码重用代码？要么
>通过共享库/动态库(所有头文件)重用代码
无论它是什么：减少重复代码(复制粘贴综合症)的策略是什么,代码膨胀？
具体例子：
以下是我们在组织中共享代码的方式：
我们使用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)
附录:(如果你愿意,请阅读)
On top of that,what C++ makes easy is
not creation of reusable binary
components; rather,C++ makes it
relatively easy to reuse source code.
Note that most major C++ libraries are
shipped in source form,not compiled
form. It’s all too often necessary to
look at that source in order to
inherit correctly from an object—and
it’s all too easy (and often
necessary) to rely on implementation
details of the original library when
you reuse it. As if that isn’t bad
enough,it’s often tempting (or
necessary) to modify the original
source and do a private build of the
library. (How many private builds of
MFC are there? The world will never
know . . .)
也许这就是为什么当你查看像Intel Math Kernel库这样的库时,在他们的“lib”文件夹中,每个Visual Studio版本都有“vc7”,“vc8”,“vc9”.可怕的东西.
或者this断言怎么样：
C++ is notorIoUsly non-accommodating
when it comes to plugins. C++ is
extremely platform-specific and
compiler-specific. The C++ standard
doesn’t specify an Application Binary
Interface (ABI),which means that C++
libraries from different compilers or
even different versions of the same
compiler are incompatible. Add to that
the fact that C++ has no concept of
dynamic loading and each platform
provide its own solution (incompatible
with others) and you get the picture.
你对上述断言的看法是什么？像Java或.NET这样的问题会面临这些问题吗？例如如果我从Netbeans生成一个JAR文件,只要我确保它们都兼容JRE / JDK,它会导入IntelliJ吗？
