c – STL和释放/调试库混乱

前端之家收集整理的这篇文章主要介绍了c – STL和释放/调试库混乱前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我正在使用一些第三方.我使用它的共享库版本,因为库是大(约60MB),被几个应用程序使用.

应用程序启动有没有办法找出这个版本/调试版本的库是否分别用于我的应用程序的版本/调试版本?

更长的描述

暴露C接口的库.一个API方法返回std :: vector< std :: string&gt ;. 当我在调试模式下编译我的应用程序时,应该使用调试版本的库的问题.相同的释放.如果使用不正确的库版本,应用程序将崩溃. 根据gcc(见http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt03ch17s04.html)

but with a mixed mode standard library
that could be using either debug-mode
or release-mode basic_string objects,
things get more complicated

附: 1

看起来Timbo的提案是一个可能的解决方案 – 使用不同的soname进行调试和发布库.那么,应该传递给./configure脚本来更改库的soname?

附: 2

我的问题不是链接时间,而是在运行时.

附: 3

Here是我面临的问题演示的问题.

解决方法

我相信您在提供的链接中误读了该文档.特别是,您误解了其目的 – 该部分标题为“目标”,并描述了C调试库的一些假设设计以及这些设计的后果,以便解释所做的实际设计选择.按照您引用的行的文本位描述了由假设实现而产生的混乱,这些实现具有针对释放模式和调试模式字符串的单独设计.继续说:

For this reason we cannot easily provide safe iterators for the std::basic_string class template,as it is present throughout the C++ standard library.

(或者,改写,提供一个特殊的“调试”版本的字符串迭代器是不可能的.)

With the design of libstdc++ debug mode,we cannot effectively hide the differences between debug and release-mode strings from the user. Failure to hide the differences may result in unpredictable behavior,and for this reason we have opted to only perform basic_string changes that do not require ABI changes. The effect on users is expected to be minimal,as there are simple alternatives (e.g.,__gnu_debug::basic_string),and the usability benefit we gain from the ability to mix debug- and release-compiled translation units is enormous.

换句话说,GCC的libstdc中的调试和释放模式的设计已经针对字符串的单独设计拒绝了这个假设实现,特别是为了允许跨模式链接您担心如何避免的排序.

因此,您不应该在编译库时遇到问题,而不用使用-D_GLIBCXX_DEBUG(或者由于某种原因而需要),并将其链接到应用程序的任一模式.如果你有问题,那是由于某个地方的错误. [但请参阅下面的编辑!这是特定于std :: string,而不是其他容器!]

编辑:答案接受后,我跟进了std::vector<std::string> crash的后续问题,并意识到这个答案的结论是不正确的. GCC的libstdc使用字符串来巧妙地支持“每次使用重新编译”(其中给定容器对象的所有使用必须使用相同的标记进行编译,但是在程序中使用相同的容器类不需要编译相同的标志),但这并不完全相同的事情,完整的“单位编译”,将提供您需要的交互能力.具体来说,文件说明了交联能力,

We believe that this level of recompilation is in fact not possible if we intend to supply safe iterators,leave the program semantics unchanged,and not regress in performance under release mode….

因此,如果您在库界面中传递容器,则需要两个独立的库.老实说,对于这种情况,我发现最简单的解决方案只是将两个库安装到不同的目录中(每个变体都有一个),并且您希望两者都与主库目录分开.或者,您可以重命名调试库文件,然后手动安装.

作为一个进一步的建议 – 你可能不会经常在调试模式下运行它.可能只能将调试版本静态编译并链接到应用程序中,因此您不必担心安装多个动态库并在运行时保持直线.

猜你在找的C&C++相关文章