Re: STL objects and binary compatibility

James Kanze <james.kanze@[EMAIL PROTECTED]
> wrote in news:acd6384e-e719-4324-
9dca-7a482ec368bc@[EMAIL PROTECTED]
> On May 6, 9:10 pm, Gianni Mariani <gi4nos...@[EMAIL PROTECTED]
> wrote:
>> osama...@[EMAIL PROTECTED]
 wrote:
[...]
>> > Sorry my question was not very clear. In other words, can
>> > STL Objects cross DLL boundaries. For example. Can we pass
>> > STL objects between different binaries by reference safely?
> 
>> Only if you're using the same STL library (or binary
>> compatible library).  This usually means you're stuck with
>> making sure that the DLL versions are using the same compiler
>> major revision.
> 
> And the same compiler options.  At least some of them can also
> affect the binary compatibility.  Using g++, try linking code
> compiled with -D_GLIBCXX_DEBUG, and code compiled without it.
> (Actually, it links just fine---it just crashes at runtime.)
> And while I've not actually tried it, I would expect similar
> problems with VC++ using mixtures of /Gd, /Gr and /Gz or
> different values of /vm<x> or /Zc:wchar_t.  (In practice,
> without /vmg, you'll get binary incompatibility anyway.)

The current annoyance in VC++ is the _SECURE_SCL thing; it is on by 
default in both Debug and Release builds. IMHO it should be switched off  
in optimized builds (what would be the point of optimization otherwise?). 

There was a recent thread in this NG about C++ and Java speed wars where 
C++ honour could only be saved by turning _SECURE_SCL off...

However, if some DLL-s happen to be compiled with different settings and 
are trying to expose or exchange STL containers or iterators, the program 
will crash at run-time with mysterious error messages.

Note that this is a preprocessor definition which can reside in an header 
file as well, so even ensuring the same compiler options does not 
guarantee binary compatibility. In a quality implementation binarily 
incompatible object files should not link, but it seems this is not the 
case in practice.

Paavo