c++ - 轻松地将许多重要的 "static library projects"重构为 "dll projects"

Question

我有 6 个静态库项目:-

- Math
- ECS             : depends on Math
- Utility         : depends on ECS
- Physics         : depends on Utility         
- Graphics        : depends on Utility     
- BaseGame        : depends on Physics and Graphics         
- Some game (.exe): depends on BaseGame      
(The "depends" here is transitive e.g. BaseGame also depends on ECS.)    

我通过“静态库”技术成功地使用了 6 个项目。

今天听说动态库可以减少编译时间(暂且不讨论是否属实)，
所以我阅读了以下链接并成功创建了一个小演示。

• https://learn.microsoft.com/en-us/cpp/build/walkthrough-creating-and-using-a-dynamic-link-library-cpp?view=vs-2019 (官方)
• https://www.badprog.com/c-windows-creating-a-dynamic-link-library-dll (备选)
• How do I build an import library (.lib) AND a DLL in Visual C++? (故障排除)

这是我的测试演示中的一些代码:-

#ifdef SomeName1_EXPORTS
#define SomeMacro1 __declspec(dllexport) 
#else
#define SomeMacro1 __declspec(dllimport) 
#endif
SomeMacro1 void someFunction(int someParam);

现在，是时候将它应用到我的实际项目中了。

第一步，我想导出我的 6 个库的所有函数和类。
我假设我必须向所有 6 个项目(~100K 行)中的每个函数添加 SomeMacro1(每个项目不同)，对吗？

这是一个巨大的重构。
有没有更简单的方法？我是否错过了一些非常重要的事情？

其他注意事项 :-

• 我想轻松地将我的库项目切换回静态库(以防出现问题)。
• 我更喜欢跨平台解决方案。 (例如，如果我以后想在 Linux 中运行，则不需要普遍重构)
• 我更喜欢这样一种解决方案，即当我将一个源文件从一个项目剪切并粘贴到另一个项目时，重构(在代码中)的成本不会比正常情况增加。
  (SomeMacro1 目前具体到一个项目)

类似问题:How to convert a static library project into a dll project in VS2005

赏金原因

感谢 Andriy Tylychko 的回答提供了有用的警告，并暗示重构将不可避免地变得复杂，但我仍然相信有一些简单的方法可以重构我的项目。

现在，我想将我的库项目更改为动态库。 (更快的编译)
然后当我发布我的产品时，我会将它们转换回静态库。 (更好的表现)

编辑 Robert Andrzejuk 由于他在评论中的链接而获得赏金。 ( https://learn.microsoft.com/en-us/cpp/cpp/using-dllimport-and-dllexport-in-cpp-classes?view=vs-2019 )
这听起来可能很简单，但我从来不知道我可以在类级别__declspec(dllexport)。
虽然这不是我的梦想，但它让很多事情变得更容易。

Answer 1

严格来说，转换为 DLL 将主要减少链接时间，但您会注意到(在大多数情况下是微妙的)性能下降，因为现在“整个程序优化”的优化空间要小得多，例如跨不同二进制文件的内联函数。

动态链接库和静态链接库是完全不同的野兽，DLL 需要更多的关注。您需要仔细设计他们的公共(public) API 并相应地定义它(通常通过您提供的宏)。例如。不建议在依赖于特定类型的 C 运行时(如调试和发布)的 DLL 公共(public) API 中使用标准库类型(以及许多其他类型)——主要是关于在一个二进制文件中分配内存并在另一个二进制文件中释放，应该避免。但这并不总是一个问题。

在静态库和动态库之间来回切换没有多大意义。

静态库通常要简单得多，并且不关心公共(public) API，因为一切都可以从外部自动访问。例如。数学库通常是静态的，因为无论如何都应该导出几乎所有功能，并且它们(通常)没有任何复杂的内部“业务”逻辑。

具有您想隐藏的“业务”逻辑(例如，可以更自由地修改它)和定义明确的公共(public) API 的更大库会带来长期利益。例如。如果 API 未更改，您只能更新一个小的 DLL 而不是巨大的单体 EXE。

由于很难提前仔细计划，因此随着项目的成熟，将静态库转换为 DLL(一次)的需求经常发生。在这种情况下，您不需要导出每个类和函数，而是仔细选择确切应该导出的内容，并理想地重构现有 API 以更好地适应新的现实。幸运的是，您似乎没有任何循环依赖关系，因为它们可能会增加很多麻烦。

跨 DLL 的重构不可避免地变得更加复杂，但这应该不是什么大问题。如果你的库看起来应该是一个 DLL - 让它成为一个 DLL，那么复制/粘贴不是那么容易，那么优点将大于缺点。

从你的例子来看，由于知识非常有限，所以这纯粹是猜测，看起来只有 Physics 和 Graphics 应该是 DLL，也可能是 BaseGame。