On May 8, 11:08 pm, Paavo Helde <nob...@[EMAIL PROTECTED]
> wrote:
> James Kanze <james.ka...@[EMAIL PROTECTED]
> wrote in news:acd6384e-e719-4324-
> 9dca-7a482ec36...@[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.
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@[EMAIL PROTECTED]
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
|
