James Kanze <james.kanze@[EMAIL PROTECTED]
> wrote in news:1ca237c6-8137-4915-a076-
a06dd96c2162@[EMAIL PROTECTED]
> 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
I'm developing kind of library which will be used and reused in yet
unknown
situations. Performance is often the issue. So if I can gain any speed by
a
so simple way as turning off a nearly useless (at least for me - this
feature has produced only false alarms for me so far) compiler feature, I
will certainly want to do that.
> 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.
Yes.
> From 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
In this case, the Checked Iterators are enabled by default in both builds,
thus probably being binary compatible (never tried). I would say this
would
be the only justification of this feature (to be included in the Release
build). OTOH, in order to mix Debug and Release builds in such a way one
has to solve the conflicts appearing from multiple runtime libraries
first,
which is not an easy task (and not solvable by command-line switched
AFAIK).
> 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.
Yes, it appears there is some room for improvement in our build system -
it
is not currently possible to change build options globally. Currently each
project is compiled with its own private project file, the problems appear
if different projects happen to be compiled with different binarily
incompatible options.
>
>> 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).
This is UB only formally, only from POV of C++ standard. These macros are
documented in the compilers' documentation, so any code which uses them
has
implementation-defined behavior. Of course, VC++ documentation fails to
note the binary incompatibility issues, so the implementation-defined
behavior is actually not very well defined here...
Unfortunately, twiddling the macros is exactly what I'm trying to do
(#define _SECURE_SCL 0 in the Release build). I will need much more
convincing before giving it up.
Thanks for your answers!
Paavo
|
