VS 项目中的 STL 矢量损坏
我有一个 Visual Studio 2005 解决方案，其中包含几个彼此独立构建的项目。主项目静态链接其他项目。我在这些静态链接库之一中遇到了非常奇怪的 STL 矢量损坏问题。例如，我声明一个 std::vector，然后执行 sort( thatVector.begin(), thatVector.end() )，但是当我调试它并查看反汇编时，我看到了这个：
std::vector<SomeOtherClass<SomeOtherTemplateType>,std::allocator<SomeOtherClass<SomeOtherTemplateType> > >::begin
令人难以置信的奇怪的是， SomeOtherClass 和 SomeOtherTemplate 是在主项目中声明的，所以这个库应该完全不知道它们。
我尝试冻结所有其他线程，认为其中一个可能正在损坏 thatVector，但没有骰子。我完全不知所措。有人经历过这样的事情吗？
编译信息： - 主程序/Zi，自定义优化（基本上是可调试的发布版本） - 静态库 /Zi、/Od
链接信息： /调试
I have a Visual Studio 2005 solution with several projects that build independently of each other. The main project statically links the other projects. I'm getting very strange STL vector corruption in one of those statically-linked libraries. For example, I declare a std::vector and then perform a sort( thatVector.begin(), thatVector.end() ), but when I debug it and look at the disassembly, I see this:
std::vector<SomeOtherClass<SomeOtherTemplateType>,std::allocator<SomeOtherClass<SomeOtherTemplateType> > >::begin
The incredibly odd thing is that SomeOtherClass and SomeOtherTemplate are declared in the main project, so this library should have absolutely no knowledge of them whatsoever.
I've tried freezing all other threads, thinking that perhaps one of them was corrupting thatVector, but no dice. I'm at a complete loss. Has anyone experienced something like this?
Compile info:
- main program /Zi, custom optimization (basically a debuggable release build)
- static library /Zi, /Od
Link info:
/DEBUG
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
问题在于库和程序是使用不同的编译器选项编译的。结果，您得到了不同的迭代器实现，但具有相同的签名。这是已知问题 并且 Microsoft 建议编译多个版本的静态链接库，并将可执行文件与适当的版本链接起来。
The problem is that library and program have been compiled with different compiler options. As the result you've got different iterators implementation but with the same signature. It is known problem and Microsoft recommends to compile several versions of statically linked libraries and link executable with appropriate one.
向量是模板类型，这意味着引用向量的每段代码都必须知道完整的类型。您的库不仅可以了解 SomeOtherClass 和 SomeOtherTemplateType，而且还必须了解它们才能引用它们的向量。
在这种情况下，向量的完整类型是：
...可能在代码中声明如下：
...分配器解析为默认模板参数。
现在，谈谈你的腐败问题。关于腐败的性质没有太多信息，因此我将做出一些假设。 Nameley，您在一个模块中分配向量并尝试在另一个模块中对其执行某些操作（例如将其推入其中），并且当您在另一个模块中执行某些操作时，实际上会发生损坏发生。令人沮丧的是，在许多这样的情况下，当损坏发生时，并没有检测到或报告损坏。它通常是在很久以后才在完全不相关的代码中检测到的。
如果上述假设正确，我对可能的原因有 2 个建议：
模块没有链接到相同的版本和版本。运行时库的风格。尝试确保每个模块链接到相同的 CRT（例如 Windows 下的多线程调试 DLL），然后重试。大多数时候，这就是问题所在。
您正在使用不同的编译器（或同一编译器的不同版本）来创建不同的模块。在这种情况下，向量对于一个模块来说看起来像是一件事，而对于另一个模块来说看起来像是另一件事。有许多线程间接讨论此类问题，请参阅 这里举一个例子。
A vector is a templated type, meaning that every piece of code that refers to the vector must know the complete type. Not only can your library knwo about SomeOtherClass and SomeOtherTemplateType, they must know about them in order to refer to a vector of them.
In this case, the complete type of your vector is:
...which is probably declared in your code something like this:
...with the allocator resolving to a default template argument.
Now, on to your corruption problem. There isn't much information to go on about the nature of the corruption, so I am going to make a few assumptions. Nameley that you allocate the vector in one module and try to do something with it (like
push_backin to it) in another module, and that it is when you do something in the other module when the corruption actually occurs. Frustratingly, in many of these cases the corruption isn't detected or reported at the moment when the corruption occurs. It often is detected much later in totally unrelated code.If the above assumptions are correct, I have 2 suggestions as to the possible cause:
The modules are not linked to the same version & flavor of the runtime libraries. Try making sure that each module links to the same CRT (for example, Multithreaded Debug DLL under Windows) and try again. Most of the time, this is the problem.
You are using different compilers (or different versions of the same compiler) to create the different modules. In this case, a vector looks like one thing to one module and looks like something else to another module. There are many threads that indirrectly discuss this kind of problem, see here for one example.