link against stl (different implementation of)

[Ricky Corsi]

hello everybody,
I have an application that uses a 3D engine library compiled as a
static library called EnRG.lib. My own code is normally compiled
against the MS Visual C implementation of the stl, and everything
works fine.
I wanted to try to link the same code against the stlport. but I get a
lot of linking errors (i report one of those at the end of the
message) and I don't understand why...
could it be because the EnRG lib is compiled with the MS's stl?? being
it a static lib, shouldn't it incorporate the code it needs and leave
me free to link my own code against the library that I prefer?
any hint??
thank you
Ricky

error example:
cameraUtils.obj : error LNK2001: unresolved external symbol
"public: bool __thiscall
EnRG::Graphics: :Win32DisplayMa nager::Register WndClass(class_ STL::basic_stri ng<char,class
_STL::char_trai ts<char>,class _STL::allocator <char> > const &,unsigned
long,unsigned long,unsigned long,unsigned long)"
(?RegisterWndCl ass@Win32Displa yManager@Graphi cs@EnRG@@QAE_NA BV?$basic_strin g@DV?$char_trai ts@D@_STL@
@V?$allocator@D @2@@_STL@@KKKK@ Z)

[Dietmar Kuehl]

Ricky Corsi wrote:

I have an application that uses a 3D engine library compiled as a
static library called EnRG.lib. My own code is normally compiled
against the MS Visual C implementation of the stl, and everything
works fine.
I wanted to try to link the same code against the stlport. but I get a lot of linking errors (i report one of those at the end of the
message) and I don't understand why...
The library implementations and declarations differ in rather many
aspects: Although they should be source compatible, it is almost
certain that they are not binary compatible.
could it be because the EnRG lib is compiled with the MS's stl??
Quite likely.
being
it a static lib, shouldn't it incorporate the code it needs and leave
me free to link my own code against the library that I prefer?

No: there can only be one standard library in a program. Actually,
you are even more restricted than you think you are: using a
compiler with a different standard library than the one shipping
with the compiler is not guaranteed to work at all! After all, the
compiler generates code dependant on standard library classes. For
example, 'std::bad_cast' is defined by standard library but the
throw statement is generated by the compiler when you do a
dynamic_cast on a reference. There are things a library implementor
can do to avoid most of the problems. One of the options is to
implement the replacement library in a different namespace than
'std' and then use macro magic to make it appear as if it is in
namespace 'std'. Of course, this means that *both* the original
and the add-on standard library need to be linked! (I think this is
the approach taken by STLPor).
--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting

[Ricky Corsi]

Dietmar Kuehl wrote:

Ricky Corsi wrote:

I have an application that uses a 3D engine library compiled as a
static library called EnRG.lib. My own code is normally compiled
against the MS Visual C implementation of the stl, and everything
works fine.
I wanted to try to link the same code against the stlport. but I get
a

lot of linking errors (i report one of those at the end of the
message) and I don't understand why...

The library implementations and declarations differ in rather many
aspects: Although they should be source compatible, it is almost
certain that they are not binary compatible.

could it be because the EnRG lib is compiled with the MS's stl??

Quite likely.

being
it a static lib, shouldn't it incorporate the code it needs and leave
me free to link my own code against the library that I prefer?

No: there can only be one standard library in a program. Actually,
you are even more restricted than you think you are: using a
compiler with a different standard library than the one shipping
with the compiler is not guaranteed to work at all! After all, the
compiler generates code dependant on standard library classes. For
example, 'std::bad_cast' is defined by standard library but the
throw statement is generated by the compiler when you do a
dynamic_cast on a reference. There are things a library implementor
can do to avoid most of the problems. One of the options is to
implement the replacement library in a different namespace than
'std' and then use macro magic to make it appear as if it is in
namespace 'std'. Of course, this means that *both* the original
and the add-on standard library need to be linked! (I think this is
the approach taken by STLPor).

Thanks Dietmar.
So this means that when you build a static lib, it takes internal
reference to the symbols deriving from the STL right?
And this means also that when you get for instance an open source
library from the web,
- either you recompile it with the STL you want to use
- either (in case you use the precompiled version) you must adapt and
use the same stl implementation the precomp. library uses.
Am I right? this is pretty annoying...

One last question: can you give me some more details or suggest a
reading for the "macro magic" trick? I never heard about it before...

thank you
ricky

--
<mailto:di***** ******@yahoo.co m> <http://www.dietmar-kuehl.de/>
<http://www.contendix.c om> - Software Development & Consulting