incompatible STL?

This is a discussion on incompatible STL? within the C++ Programming forums, part of the General Programming Boards category; Hi, I compiled the QT framework using VS2005 and developed some applications linking against it which also make use of ...

  1. #1
    Registered User
    Join Date
    Nov 2006
    Posts
    519

    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.

  2. #2
    Registered User
    Join Date
    Aug 2003
    Posts
    1,197
    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.

  3. #3
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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.

  4. #4
    Registered User
    Join Date
    Aug 2003
    Posts
    1,197
    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.

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    5,827
    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.
    Right 98% of the time, and don't care about the other 3%.

  6. #6
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by Shakti View Post
    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.

  7. #7
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by grumpy View Post
    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 :/

  8. #8
    Registered User
    Join Date
    Jun 2005
    Posts
    5,827
    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.
    Right 98% of the time, and don't care about the other 3%.

  9. #9
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by grumpy View Post
    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.

  10. #10
    Registered User
    Join Date
    Jun 2005
    Posts
    5,827
    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.
    Last edited by grumpy; 11-30-2010 at 03:46 AM.
    Right 98% of the time, and don't care about the other 3%.

  11. #11
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    3,797
    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

  12. #12
    Registered User
    Join Date
    Jun 2005
    Posts
    5,827
    Quote Originally Posted by phantomotap View Post
    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.
    Right 98% of the time, and don't care about the other 3%.

  13. #13
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    And the drawback is what I start now over to generate a different set of .def files for the new VS2010. Fun.

  14. #14
    Registered User
    Join Date
    Jun 2005
    Posts
    5,827
    Quote Originally Posted by pheres View Post
    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.
    Right 98% of the time, and don't care about the other 3%.

  15. #15
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    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)

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Passing Argument from incompatible pointer type
    By AmritxD in forum C Programming
    Replies: 3
    Last Post: 08-15-2010, 03:23 PM
  2. The Interactive Animation - my first released C program
    By ulillillia in forum A Brief History of Cprogramming.com
    Replies: 48
    Last Post: 05-10-2007, 02:25 AM
  3. Compiler "Warnings"
    By Jeremy G in forum A Brief History of Cprogramming.com
    Replies: 24
    Last Post: 04-24-2005, 01:09 PM
  4. Prime Number Generator... Help !?!!
    By Halo in forum C++ Programming
    Replies: 9
    Last Post: 10-20-2003, 07:26 PM
  5. include question
    By Wanted420 in forum C++ Programming
    Replies: 8
    Last Post: 10-17-2003, 03:49 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21