STL Vector Corruption Across VS Projects

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 absolu开发者_如何学编程tely 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

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.

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:

std::vector<SomeOtherClass<SomeOtherTemplateType>,std::allocator<SomeOtherClass<SomeOtherTemplateType> > >

...which is probably declared in your code something like this:

vector<SomeOtherClass<SomeOtherTemplateType> > thatVector;

...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_back in 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:

1. 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.

2. 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.