Re: STL objects and binary compatibility
On May 8, 11:08 pm, Paavo Helde <nob...@ebi.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in news:acd6384e-e719-4324-
9dca-7a482ec36...@i76g2000hsf.googlegroups.com:
On May 6, 9:10 pm, Gianni Mariani <gi4nos...@mariani.ws> wrote:
osama...@gmail.com 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.
I don't think so. You define whether it is on or off when you
invoke the compiler; you can turn it off in debug builds, and
leave it on in release builds, if that's what you want.
Typically, of course, you'll want it on in both. Typically, of
course, you'll want exactly the same compiler options in your
debug builds as in your release builds, so that your unit tests
test the code that is actually delivered.
IMHO it should be switched off in optimized builds (what
would be the point of optimization otherwise?).
Well, obviously, if the profiler shows you have performance
problems due to the extra checks, then you'll have to turn it
off. I'm not familiar enough with VC++ to be sure, but I rather
suspect that you have to compile everything with the same value
for it; in other words, that it affects binary compatibility.
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...
There are a couple of recent threads in this NG that are full of
nonsense. Who cares?
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.
In other words, it affects binary compatibility.
=46rom what I've been led to believe, if you use the default
settings for release and debug builds in Visual Studios, you
don't have binary compatibility between the two. I'll admit
that I only have hearsay for that, however, since I've yet to
find a compiler where the default settings were usable for
anything serious, VC++ included. I systematically set things as
I need them.
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.
Yes. This is exactly the problem I was talking about with g++.
And you've got a good point about something being defined (or
undef'ed) in a header: _GLIBCXX_DEBUG is also, formally, a
macro.
Of course, both _GLIBCXX_DEBUG and _SECURE_SCL are squarely in
the implementation namespace. Any code which does anything with
them is invoking undefined behavior. So the answer to that is:
don't do it (and don't use any third party code which is so
poorly written as to do it).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34