我想为其他程序员编写一个（静态）库，使用编译器的优化。
在使用调试版本编写和测试库的过程中，我发现它的运行速度非常慢，但是如果我切换到发布版本，那么它看起来速度可以接受。
目前我已经将库编译为调试版本，并且我在另一个项目中使用它，我注意到它的运行速度有多慢，但如果我尝试将我的新项目切换到发布版本，那么链接失败了很多这样的错误：
LIBCMTD.lib（tzset.obj）：错误LNK2005：__tzset已在MSVCRT.lib（MSVCR90.dll）中定义
在构建我的库时，我应该使用哪些设置，以便程序员可以在自己的项目中使用该库，以便无论是使用调试还是发布版本，它都可以快速运行？
答案 0 :(得分：4)
这是静态库的老问题：它必须使用与其链接的可执行文件的相同CRT，否则链接器将找到相同CRT例程和数据结构的冲突版本（公共和内部的） ）。
由于目前有4个版本的CRT（所有调试/发布和dll /静态链接组合），您应该提供4个不同的.lib文件库。顺便说一句，这是几乎没有人以.lib形式分发静态库的原因之一（除非它们只是导入库），但提供了以库用户喜欢的任何方式编译的源。
如果您不喜欢这样，您应该考虑将您的库分发为dll。在最后一种情况下，您仍然必须小心CRT，因为如果dll和使用它的程序不共享相同的CRT（例如，其中一个使用CRT的静态链接版本，或者它们使用不同的版本动态链接CRT）您不能依赖几个C ++工具才能正常工作;最明显的问题是你不能delete由另一个模块用new分配的东西，因为这两个CRT使用两个分开的堆。
此外，尝试跨模块传递C ++库中定义的类型可能会导致问题，因为没有什么能保证它们在不同的CRT版本之间是二进制兼容的（通常它们不会）。如果您不匹配CRT，RTTI和例外也是有问题的区域。
长话短说：使用静态库，必须匹配CRT，否则各个模块将不会链接在一起。使用dll，正确匹配CRT，一切都应该正常工作。否则，唯一明智的选择是提供C风格的接口并让每个模块管理其内存分配（可能导出其malloc / free以让其他模块从模块的堆中分配/释放内存）。
答案 1 :(得分：3)
您必须同时提供调试和发布版本。如果要在其中调试代码，则无法发送一个库以在调试和发布模式下使用。
答案 2 :(得分：0)