在闭源库中使用 STL
在一个库中使用一个符合标准的 STL，而在使用该库的项目中使用另一个 STL 是否安全？例如：
//library.h
#include <string> //let's say here it uses minGW STL
void Foo(std::string& str_mingw);
//library.cpp
void Foo(std::string& str_mingw) { /*do something*/ }
//application.cpp
#include "library.h"
#include <string> //let's say here it uses VStudio STL
void Bar()
{
std::string str_vstudio;
Foo(str_vstudio);
//Foo() inside the .lib or .dll uses string from minGW,
//but here a string from VStudio is used
}
在我看来，糟糕的事情将会发生，特别是如果使用的不是简单的字符串而是像 tr2::thread 这样更复杂的东西。但如果是这样，我如何在一个编译器中编译一个库，并让库用户为他们的项目自由选择他们喜欢的编译器？
Is it safe to use one standard compliant STL in a library, and another in a project that uses that library? For example:
//library.h
#include <string> //let's say here it uses minGW STL
void Foo(std::string& str_mingw);
//library.cpp
void Foo(std::string& str_mingw) { /*do something*/ }
//application.cpp
#include "library.h"
#include <string> //let's say here it uses VStudio STL
void Bar()
{
std::string str_vstudio;
Foo(str_vstudio);
//Foo() inside the .lib or .dll uses string from minGW,
//but here a string from VStudio is used
}
It seems to me that bad things will happen, especially if what is used isn't simple string but something more complicated like tr2::thread. But if so, how can I compile a library in one compiler and let the library users freely choose their preferred compiler for their projects?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果 - 通过库 - 你的意思是动态库 - 简单的答案是：否，复杂的答案是：否。
C++ 和动态库是一个非常非常脆弱的前景。任何小的更改都需要重建所有模块，并且每个库使用的运行时必须是完全相同的库实例。
即使您设法跨 dll 边界获取 std::string - 虽然 std::string 的外部接口是固定的，但任何实现差异都会使数据看起来损坏。
仅当运行时可能不同时，在动态库之间传递简单的 POD 结构和本机数据类型才是安全的 - 即使这样，也必须注意正确管理对象生命周期 - 分配库必须是解除分配库。
如果您指的是静态库 - 这没有多大意义 - 我认为 MinGW 制作的库不会与 MSDev 兼容，并且 MSDev 库与 MinGW 不兼容。即使 lib 文件格式名义上应该兼容 - 假设不同的名称修改不会导致阻止成功的 ling：将使用最终链接环境的 STL 库。
If - by library - you mean dynamic library - The simple answer is: no and the complex answer is: no.
C++ and dynamic libraries is a very VERY fragile prospect. Any small change requires a rebuild of all modules, and the runtime used by each library MUST be the exact same library instance.
Even if you managed to get a std::string across a dll boundary - while the external interface of std::string is fixed, any implementation differences will make the data appear corrupted.
It is only safe to pass simple POD structs and native data types between dynamic libraries if the runtimes are potentially different - and even then care must be taken to manage object lifetimes correctly - the allocating library MUST be the de-allocating library.
If you mean static library - that doesn't make a huge amount of sense - I dont think that libs made by MinGW will be compatible with MSDev and MSDev libs are incompatible with MinGW. Even should the lib file format be nominally compatible - assuming the different name manglings don't cause prevent a successful ling: the STL library of the final linking environment would be used.
不会。
为了可重用性，STL 的某些部分被放入共享库中。不可能保证类的内部结构在不同的 STL 中匹配，因此如果程序互换使用两者，则会导致偶发性崩溃。
另请注意，来自不同供应商的 STL 可能具有不同的内部名称空间和类组织。这会导致公共符号
std::basic_string可能具有不同的内部名称，并且会以不同的方式进行破坏，从而使void Foo(std::string& str_mingw);和 < code>void Foo(std::string& str_vstudio); 从链接器的角度来看是两个不同的函数。No.
Some parts of STL for reusability are put into a shared library. It is impossible to guarantee that the internal structure of classes would match in the different STLs thus leading to sporadic crashes if both are used by a program interchangeably.
Also note that STLs from different vendors might have different organization of internal namespaces and classes. That has the effect that public symbol
std::basic_stringmight have different internal names and would be mangled differently, makingvoid Foo(std::string& str_mingw);andvoid Foo(std::string& str_vstudio);from linker perspective two different functions.这取决于库、平台以及编译和链接的方式。通常（尤其是在 Windows 上）库作为 DLL 分发，并且对于边界上的内容以及每个库需要如何编译都有非常具体的规则。
例如，Boost 构建 DLL 用于：
请参阅 http://beta.boost.org/doc/libs/1_36_0/more/getting_started/windows.html#library-naming 的排列。
所以是的，这是一个大问题。
It depends on the library, platform, and how you compile and link it. Often (esp on Windows) libraries are distributed as DLLs, and there are very specific rules about what can be on the boundaries, and how each needs to be compiled.
Boost, for instance, builds DLLs for:
See http://beta.boost.org/doc/libs/1_36_0/more/getting_started/windows.html#library-naming for the permutations.
So yes, it's a big problem.
不，它甚至与动态没有太多关系图书馆。即使您设法以某种方式将 MS std::string 和 MinGW std::string 链接到同一个可执行文件中，它仍然会中断。您的程序中有两个单独的（可能不同的） std::string 定义，如果您混合它们，您将处于未定义的行为状态。
但请注意，如果您的 std::string 未在界面中使用，它就会起作用。也就是说：只要您在接口级别使用 const char* （作为示例），您就可以拥有一个内部使用 MinGW 字符串的库和另一个内部使用 VC 字符串的库。
No. It doesn't even have too much to do with dynamic libraries. Even if you managed to somehow link both the MS std::string and the MinGW std::string into the same executable it would still break. You have two separate (likely different) definitions of std::string in your program and if you mix them you are in undefined behavior land.
Note however, that it would work if your std::string is not used in the interface. That is: you can have one library that uses MinGW strings internally and another lib that uses VC strings internally as long as you use const char* (as an example) at the interface level.