我们一直在将Java和.NET API库转换为C ++,并且正在尝试找出将编译版本分发给其他开发人员以与其自定义应用程序一起使用的最佳方法。它应该是静态库还是动态库?
我们需要为Win32和Win64创建(我想每个目标操作系统的Debug和Release版本)。鉴于我遇到的所有挫折都试图确保所有引用的库都匹配(/ MT与/ MD),我想知道是否有决定在这里制作,这将为其他开发人员简化它。
当我在静态库上运行dumpbin /all <static library file name> | find /i "msvc
时,我没有看到任何运行时引用(与我在.exe或.dll上执行相同操作时不同)。这是否表明运行时尚未链接,这使开发人员在开发和构建自己的应用程序时能够更灵活地制作/ MT或/ MD?
哪种方法可以让开发人员的生活更轻松?
答案 0 :(得分:4)
静态库更容易创建,但很多更难分发。客户端程序员将把它们链接到他的程序中,因此编译设置与他的兼容非常重要。您必须至少分发4个版本,对应4个不同的CRT版本(/ MD,/ MDd,/ MT,/ MTd)。并且您需要将其乘以常用的Visual Studio版本的数量。如果您不知道客户端程序员将要使用什么,那么这可能是一个非常大的列表。
DLL没有问题,你只为导出的函数声明提供一个.h,一个.lib,它是DLL的导入库(没有代码,只包含名称)和.dll本身。
然而,为您的DLL创建可从任何C或C ++编译器使用的接口更难。您不能公开任何标准C ++库类,返回std :: string不会起作用。您无法创建任何分配调用者需要释放的内存的函数。通常不能跨越边界抛出异常。执行任何这些操作往往会导致很难诊断客户端程序员的运行时问题,这是由内存分配器和类对象布局差异不匹配引起的。 COM对象模型就是这种接口的一个例子。
这不是您使用静态库时遇到的问题。有点不小心,他们要求运行时和编译器版本匹配。如果客户端程序员遇到了一个错误的静态库,那么他也会遇到所有这些问题。和更多。静态图书馆就像青少年性行为。你犯了一个错误,并在你的余生中最终支持它。
答案 1 :(得分:3)
静态和动态(共享)库都有显着优势。也许您可以选择分发两种类型的库,并让库用户决定使用哪种库。
对于我自己,我通常使用静态库,除非我认为动态库的优点对项目有意义。
静态库的优点之一:
动态库的优点