我应该对 C++ 使用什么优化设置？图书馆
我想编写一个（静态）库供其他程序员使用，该库使用编译器的优化。
在使用调试版本编写和测试库时，我发现它运行得相当慢，但如果我切换到发布版本，那么它的速度似乎是可以接受的。
目前，我已将该库编译为调试版本，并在另一个项目中使用它，我注意到它运行的速度有多慢，但是如果我尝试将我的新项目切换到发布版本，则链接会失败并出现很多错误像这样的错误：
LIBCMTD.lib(tzset.obj) : 错误 LNK2005: __tzset 已在 MSVCRT.lib(MSVCR90.dll) 中定义
LBCMTD.lib ( 他们使用调试或发布版本？
I want to write a (static) library for other programmers to use that uses the compiler's optimisations.
Whilst writing and testing the library using debug builds I find it runs quite slowly, but if I switch to a release build then it seems to be acceptably fast.
At the moment I've compiled the library as a debug build and I'm using it in another project and I notice how slowly it runs, but if I try to switch my new project to a release build, then the link fails with lots of errors like this:
LIBCMTD.lib(tzset.obj) : error LNK2005: __tzset already defined in MSVCRT.lib(MSVCR90.dll)
What settings should I use when building my library so that programmers can use the library in their own projects so it runs acceptably quickly whether they use debug or release builds?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这是静态库的老问题：它必须使用与其链接的可执行文件相同的 CRT，否则链接器将发现相同 CRT 例程和数据结构（公共和内部）的冲突版本。
由于当前有 4 个版本的 CRT（所有调试/发布和 dll/静态链接组合），因此您应该提供库的 4 个不同的
.lib文件。顺便说一句，这就是为什么几乎没有人以.lib形式分发静态库（除非它们只是导入库），而是以库用户喜欢的任何方式提供要编译的源代码的原因之一。如果您不喜欢这样，您应该考虑将您的库作为 dll 分发。在最后一种情况下，您仍然必须小心 CRT，因为如果 dll 和使用它的程序不共享相同的 CRT（例如，其中一个使用 CRT 的静态链接版本，或者它们使用不同的版本）动态链接 CRT 的一部分）您不能依赖多个 C++ 工具来正常工作；最明显的问题是，您无法
删除其他模块使用new分配的内容，因为两个 CRT 使用两个独立的堆。此外，尝试跨模块传递 C++ 库中定义的类型可能会导致问题，因为没有任何东西可以保证它们在不同 CRT 版本之间是二进制兼容的（而且通常不会）。如果 CRT 不匹配，RTTI 和异常也是有问题的领域。
长话短说：对于静态库，您必须匹配CRT，否则各个模块将无法链接在一起。使用 dll，正确匹配 CRT，一切都会正常工作。否则，唯一明智的选择是提供一个 C 风格的接口，让每个模块管理其内存分配（也许导出其
malloc/free来让其他模块分配/释放来自模块堆的内存）。This is the old problem of static libraries: it has to use the same CRT of the executable that links against it, otherwise the linker will find conflicting versions of the same CRT routines and data structures (both the public and the internal ones).
Since there are currently 4 versions of the CRT (all the debug/release and dll/static link combinations), you should provide 4 different
.libfiles of your library. Incidentally, this is one of the reasons why almost nobody distributes static libraries in.libform (unless they are just import libraries), but provide the sources to be compiled in any way the library user prefers.If you don't like this, you should consider distributing your library as a dll. In this last case, you still must be careful about the CRT, because if the dll and the program that uses it do not share the same CRT (e.g. one of them uses the static-linking version of the CRT, or they use different versions of the dynamic-linking CRT) you cannot rely on several C++ facilities to work correctly; the most evident problem is that you cannot
deletestuff that was allocated withnewby the other module, because the two CRTs are using two separated heaps.Also, trying to pass types defined in the C++ library across the modules will probably result in problems, because nothing guarantees that they are binary compatible across different CRT versions (and often they won't). RTTI and exceptions are also problematic areas if you mismatch CRTs.
Long story short: with static libraries, you must match the CRTs, otherwise the various modules won't link together. With dlls, match correctly the CRTs and everything should work fine. Otherwise, the only wise alternative is to provide a C-style interface and let each module manage its memory allocations (perhaps exporting its
malloc/freeto let other modules allocate/free the memory from the module's heap).您必须同时发布调试版本和发布版本。如果您想调试其中的代码，则无法发布一个库以在调试和发布模式下使用。
You have to ship both debug and release builds. You can't ship one library for use in both debug and release mode, if you want debugging code in it.