来自不同 Visual C++ 的冲突 stl版本
我有一个封闭的可执行文件（没有源代码），它是用 VC++ 7.1 (VS2003) 编译的。 该可执行文件加载一个 DLL，我有该 DLL 的源代码。
我试图避免使用 VS2003 工具包编译这个 DLL，因为它涉及在我想要编译它的每台机器上安装这个工具包，并使用 makefile 而不是直接使用较新的 VS 项目。
我更改了运行时库等参数（我使用 /MT 而不是 /MD 来防止运行时 DLL 冲突）和其他一些语言切换，以保持与旧编译器的兼容性。最后它编译并与 VS2005 库良好链接。
但当我尝试运行它时，它崩溃了。原因是：DLL 将 std::string（以及其他地方的 std::vector）发送回 exe，并且冲突的 STL 实现版本会导致发生不良情况。
所以我的问题是：有没有办法解决这个问题？或者我应该继续用VC7.1工具包编译DLL？
我不是很乐观，但也许有人对此有一个好主意。
谢谢。
I have a closed executable (with no source) which was compiled with VC++ 7.1 (VS2003).
This executable loads a DLL for which I do have the source code.
I'm trying to avoid compiling this DLL with the VS2003 toolkit, because it involves installing this toolkit on every machine I want to compile it on, and to use a makefile instead of directly use the newer VS project.
I changed parameters like the runtime library (I use /MT instead of /MD to prevent runtime DLL conflicts) and some other language switches to maintain compatibility with the old compiler. Finally it compiled and linked fine with the VS2005 libs.
But then when I tried running it, it crashed. The reason: The DLL sends an std::string (and on other places - an std::vector) back to the exe, and the conflicting STL implementation versions cause something bad to happen.
So my question is: Is there a way to work around it? Or should I continue compiling the DLL with the VC7.1 toolkit?
I'm not very optimistic, but maybe someone will have a good idea regarding this.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
随着 stl 库的实现的变化，这会破坏二进制兼容性，这是（据我理解）当对象的大小/成员变量发生变化时。双方对于 std::string/vector/etc 有多大没有达成一致。
如果旧的可执行文件认为 std::string 是 32 位 char* ptr 和 32 位 size_t 长度，而新可执行文件认为 std::string 是 64 位 iterator* iterator_list、64 位 char* ptr、64 位 size_t 长度，那么它们可以不要来回传递字符串。这就是为什么长期存在的格式（windows、bmp）的第一个成员是 32 位 size_of_object。
长话短说，您需要旧的 VS2003 版本的库（我认为您不一定需要编译器）
As the implentations of the stl libraries change, that breaks binary compatability, which is (to my understanding) when the size/member variables of an object changes. The two sides don't agree on how big a std::string/vector/etc is.
If the old executable thinks a std::string is 32bit char* ptr, and 32bit size_t length, and the new executable thinks a std::string is a 64bit iterator* iterator_list, 64bit char* ptr, 64bit size_t length, then they can't pass strings back and forth. This is why long-standing formats (windows, bmp) have the first member is a 32bit size_of_object.
Long story short, you need the older VS2003 version of the library (I don't think you necessarily need the compiler)