incompatible STL?

Hi,

I compiled the QT framework using VS2005 and developed some applications linking against it which also make use of the STL.
Now I played with VS2010 and the first thing I tried of course was to compile my applications with it while I'm still linking against the QT libs compiled with VS2005.
All my apps crashed after it and as the debugger tells me, they do it while calling the QT toStdString() function.
May it be that MS broke the compatibility of the STL library between VS2005 and VS2010?

Thank you for any hints.

Yes it is a fact that the STL betwean different version of VC may be incompatible. It is generally not a good idea to use a library built with one version of VC with another version of VC or things like these might happend.

That would mean that I can't ever link any of my programs which uses the STL against any library not built by myself using the same compiler because I can't ever be sure that it uses the STL, too and may be built with another version of VS.
I wonder how the STL ever could get adapted by programmers under these preconditions.

Depends on the library but in short; yes. There are of course exceptions to this rule (for instance microsoft directx does not have this problem). Look through the documentation for the library and it will often tell you what versions it supports (and if your version is not supported it will, if open-source, often tell you how to compile the library aswell).

What do you mean "I wonder how the STL ever could get adapted by programmers under these preconditions."? STL is widely adopted by programmers but just like with any library, if you mix two versions; bad (and unforseen) things can (and probably eventually will) happend.

Things always need to be compatible between a library and programs which use that library, but these "preconditions" are not as onerous as you seem to think.

The only restriction is if the library exports function that return STL types (eg a std::vector<something>, a std::string, etc) or accept STL types as arguments. Then it is necessary that the compiler used to compile the library and the compiler used to compile the application are compatible.

As long as the library does not export such functions, there is no such problem. There is nothing, for example, preventing a library using STL types internally, but not exporting such functions.

Under windows passing arguments to a library function (or return values out) works with basic types (eg int, char, pointer to char, POD structs) if the calling conventions match - which they will, with most compilers targeting windows, by default.

That means the library needs to be designed so the interface to it (i.e. exported functions) do not use STL types - all that requires is translation of the STL types used internally by the library to types that can cross the boundary (eg convert a std::string into an array of char, and pass a pointer back). That type of thing is not particularly difficult in practice.

Quote:

---

Originally Posted by Shakti

What do you mean "I wonder how the STL ever could get adapted by programmers under these preconditions."? STL is widely adopted by programmers but just like with any library, if you mix two versions; bad (and unforseen) things can (and probably eventually will) happend.

---

Sure, but in terms of STL I don't have any direct control about the library version I or other code I want to link uses.

If I don't know with which compiler any module was built and I it also may be that the module utilizes the STL I basicly can't link against it.

Sure that problem exists with all libraries, but
a) most of the time they are linked dynamically so I just have the right verion to link against
and
b) they are not the so called _standard_ library of the programming system. Imo there shouln't be such pitfalls with it.

Quote:

---

Originally Posted by grumpy

That type of thing is not particularly difficult in practice.

---

What I know about QT is that it is quite far from the most trivial software possible, still it's programmers don't seem to get this not particulay difficult thing right by providing a toStdString() function (and probably nobody can tell if this is it's only function utilizing STL types as parameter or return type :/

Except that templates are a compile time mechanism (well, mostly). The STL, being a template library, relies on the compiler. There are benefits, in terms of performance, of doing things that way (assuming an optimising compiler).

As I said, however, there is nothing stopping you linking against a library that uses the STL, as long as STL types do not cross the library boundary (return values or arguments are not templated types).

You've also obviously never heard of "DLL hell" - dynamic link libraries have many pitfalls that make your complaints with the STL seem minor.

Quote:

---

Originally Posted by grumpy

You've also obviously never heard of "DLL hell" - dynamic link libraries have many pitfalls that make your complaints with the STL seem minor.

---

I have, even if it was a bit before of my time. I did hope though that microsoft learned something from such things, but seeing that they just breaked the binary compatibily of the _standard_ library let me doubt this.

Microsoft have done a lot to alleviate problems of DLL hell, but the problems still exist. [It's also possible to get an equivalent under other operating systems too - the phenomenon is just better known under windows].

It's not Microsoft who broke binary compatibility of the STL. The C++ standard actually specifically requires some features (eg name mangling) that have a specific purpose of breaking binary compatibility between compilers - because it allows more freedom for compilers to optimise things.

In effect, the STL is a source code library (unless the compiler comes with a linker that is much smarter than the norm, the source may be found by examining the C++ standard headers). Binary incompatibility is actually irrelevant when you have source code.

Template instantiation is a compile time mechanism, and the STL is a template-based library. Which means that compilers are allowed to (and, if different compilers lay things out differently in memory, they are required to by the C++ standard) introduce binary incompatibility with each other. That may seem perverted, but the C++ standard specifies no requirements to support things like link libraries (binary libraries are outside the scope of the C++ standard, and also are typically non-portable between operating systems).

The end effect, however, is that if you are trying to link code that has been compiled with different compilers, then you have problems. That includes any reliance on binary compatibility of libraries.

Quote:

---

that have a specific purpose of breaking binary compatibility between compilers

---

O_o

No C++ feature has such a purpose; it would be a side effect of a given feature at most.

Soma

Quote:

---

Originally Posted by phantomotap

O_o

No C++ feature has such a purpose; it would be a side effect of a given feature at most.

Soma

---

Name mangling has such a purpose. However, you're right: I stand corrected, in the sense that name mangling is not required by the C++ standard.

I was remembering the fact that the ARM originally encouraged all C++ compilers to use different name mangling schemes, and - in practice - compiler vendors continue to select their own unique encoding, sometimes changing it between compiler versions.

Without name mangling, for example, it would not be possible to support function overloading when a compiler is coupled with a traditional dumb linker (which, in practice, a significant proportion of compilers are). The reason the ARM encouraged each compiler to have a unique name mangling scheme was to prevent accidental linkage of object modules produced by different compilers that lay out non-POD classes differently in memory, have different exception handling schemes, etc etc.

And the drawback is what I start now over to generate a different set of .def files for the new VS2010. Fun.

Quote:

---

Originally Posted by pheres

And the drawback is what I start now over to generate a different set of .def files for the new VS2010. Fun.

---

Yep. Complaining about it is not going to change the need for you to indulge in such fun. It's a fact of life - in this case, it's unlikely to change.

Microsoft knows the old and the new name mangling format, it offers a build setup conversation wizard with it's IDE and the build setup includes pointers to all .def files in use. Don't you think one could expect them to spend another 5000$ to include a .def-file-conversation function? A student could write it given the encode() and decode() function they need to have somewhere anyways.
If things refuse to change it's rather because people do _not_ complain.

(sorry for complete off topic)