Home > Archive > VC STL > March 2005 > Binary compatibiltity between STL versions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Binary compatibiltity between STL versions
|
|
| John Smith 2005-03-13, 9:00 pm |
| I recently realized that not all of std::string (maybe other classes too) is
written as a header file and thus some code is put into the runtime library.
This creates a problem when compiling code with one version of the compiler
e.g. 6.0 and linking with 7.1.
It will give linker errors like:
error LNK2019: unresolved external symbol "void __cdecl std::_Xlen(void)"
(?_Xlen@std@@YAXXZ) referenced in function
So the question is how to avoid it?
One option I've found working is to not use Microsofts STL. I've tried using
STLPort which solved this trick because all their code is written in headers
only and thus no linking happens.
However it didn't support all the compilers I need yet (e.g. AMD64 support).
Another way is to write my own "mini-STL" only covering the functionality I
use.
However if it would be possible to patch the current microsoft code work
better that would be ideal.
Any ideas?
-- John
| |
| Carl Daniel [VC++ MVP] 2005-03-13, 9:00 pm |
| John Smith wrote:
> I recently realized that not all of std::string (maybe other classes
> too) is written as a header file and thus some code is put into the
> runtime library. This creates a problem when compiling code with one
> version of the compiler e.g. 6.0 and linking with 7.1.
>
> It will give linker errors like:
> error LNK2019: unresolved external symbol "void __cdecl
> std::_Xlen(void)" (?_Xlen@std@@YAXXZ) referenced in function
>
> So the question is how to avoid it?
> One option I've found working is to not use Microsofts STL. I've
> tried using STLPort which solved this trick because all their code is
> written in headers only and thus no linking happens.
That's not why it works (see below).
> However it didn't support all the compilers I need yet (e.g. AMD64
> support).
>
> Another way is to write my own "mini-STL" only covering the
> functionality I use.
>
> However if it would be possible to patch the current microsoft code
> work better that would be ideal.
>
> Any ideas?
The compatibility issues are deeper than you've realized. It's not as
simple as putting all the implementation in the header files - there are
fundamental layout changes e.g. in std::string between VC6 and VC7+. STLport
works because you're using the same library with both compilers - there's
nothing magical about all the code being in the headers.
In practice, you cannot mix VC6 STL and VC7+ STL unless they're used
completely separately (e.g. a VC7{.1}-built EXE using a VC6-built DLL).
The best solution: upgrade everything.
If you have a functional chunk that must remain in VC6 (for example, you
don't own it and the owner won't make a VC7{.1} version), then you may need
to wrap that library in an adapter (for example, re-package it as COM
objects, which are version/language independent).
-cd
| |
| John Smith 2005-03-14, 4:02 pm |
| >
> The compatibility issues are deeper than you've realized. It's not as
> simple as putting all the implementation in the header files - there are
> fundamental layout changes e.g. in std::string between VC6 and VC7+.
Yes I know that the STL versions are independent and comes from different
vendors.
But the link error I showed would never occour IF the STL implementation
would be in headers only. Then the code would have been inlined into the
objectfile beeing compiled.
> STLport
> works because you're using the same library with both compilers - there's
> nothing magical about all the code being in the headers.
Well it is kinda magic... because it works. ;-)
The "magic" part is that it doesn't use functions which has been removed in
the microsoft runtime code. If the old STL void __cdecl std::_Xlen(void)
would still be present in newest version of the library I wouldn't have had
any problems either.
> In practice, you cannot mix VC6 STL and VC7+ STL unless they're used
> completely separately (e.g. a VC7{.1}-built EXE using a VC6-built DLL).
Yeah and I am not trying to either. I wrote a static library in C++ and want
to hide all C++ references. Even if users of my library use another version
of STL then I do then they should not interfear given there are no public
names which could cause link or runtime-issues.
> The best solution: upgrade everything.
>
Unfortunatly thats no option since the users of my library use different
compiler versions. So far I've been compiling seperate versions for each
compiler to overcome this issue.
-- John
| |
| Carl Daniel [VC++ MVP] 2005-03-14, 9:00 pm |
| John Smith wrote:
>
> Yes I know that the STL versions are independent and comes from
> different vendors.
>
> But the link error I showed would never occour IF the STL
> implementation would be in headers only. Then the code would have
> been inlined into the objectfile beeing compiled.
You're right - you wouldn't get a linker error - your program would just
crash at runtime instead.
>
> Well it is kinda magic... because it works. ;-)
> The "magic" part is that it doesn't use functions which has been
> removed in the microsoft runtime code. If the old STL void __cdecl
> std::_Xlen(void) would still be present in newest version of the
> library I wouldn't have had any problems either.
Yes, you would have. The layout of std::string is changed - same interface,
radically different internals. Passing a VC7 std::string to a VC6 library
function would result in sparks, and vice-versa (even if the _XLen function
still existed).
>
> Yeah and I am not trying to either. I wrote a static library in C++
> and want to hide all C++ references. Even if users of my library use
> another version of STL then I do then they should not interfear given
> there are no public names which could cause link or runtime-issues.
In general you can't do that. If you want to completely hide your use of
libraries (STL or otherwise), you need to produce a DLL with a 'C' API. In
your case, if the STL was entirely header-based, you could "get away with
it", but it's really not a solution.
Note that there are other runtime library functions that your code may
inadvertanly depend on that aren'y compatible (or don't exist) when moving
across the VC6-VC7 boundary, so STL may not be your only problem.
-cd
|
|
|
|
|