Re: STL objects and binary compatibility
On 12 mai, 08:15, Paavo Helde <nob...@ebi.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in news:1ca237c6-8137-4915-a076-=
a06dd96c2...@w7g2000hsa.googlegroups.com:
[concerning the _SECURE_SCL option in VC++...]
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.
Can you point out an example of when it produces a false alarm?
I've almost no experience with it (since I develope almost
exclusively under Unix), but I know that the various checking
options in g++ have turned up a few errors in my own code
(mostly the concept checking), and have made others (which would
have been caught by the unit tests) far easier to localize and
fix. And I've never seen a false alarm from 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.
Yes.
Which means that you'll probably have to either deliver the
sources, and let the user compile it with whatever options he
uses, or provide several versions of it---how many I don't know.
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,
Which is simply false. Checked iterators are enabled if you ask
for them; you can enable them in all of the builds you do,
disable them in all, or use any combination you find
appropriate. (I enable them in all my builds.) You choose the
options you compile with; there's nothing which forces you one
way or the other.
thus probably being binary compatible (never tried).
There are a number of different things which can affect binary
compatibility. This is just one. As I mentionned earlier, the
only sure answer is to compile everything with exactly the same
options (which rather argues for delivering sources).
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).
What libraries you link with very definitely is controlled by
the command line. How else could they be controlled, since the
only way to invoke the compiler is by the command line? (All
Visual Studios does is create the equivalent of a command line
invocation.) Look at the /M options.
[...]
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.
Yes, but doesn't the documentation more or less say (or at least
imply) that they should be set in the command line, and not by
means of #define's/#undef's in the code. I can imagine that
including some headers, then changing their settings, and
including others, could result in binary incompatibilities
within a single source file. In other words, the implementation
has defined this "undefined behavior", but only in certain
cases.
Of course, VC++ documentation fails to note the binary
incompatibility issues, so the implementation-defined behavior
is actually not very well defined here...
That is, regretfully, a general problem. For many compilers,
jsut finding the documentation is a challenge, independently of
the quality of that which you do manage to find.
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.
What ever you do with _SECURE_SCL, do it in the command line,
not in source code. But unless there are some very strong
counter arguments, I'd recommend delivering source code, and
letting the client choose his options. (And yes, I realize that
this means additional maintenance work, since sooner or later,
you'll get a bug report concerning a combination of options you
didn't test.) Alternatively, you'll probably want a fair number
of versions of the library: full debugging support, normal
release version (with all run-time checks still in, of course),
an optimized version with run-time checks removed, a version
compiled for profiling, and possibly other variants as well, all
for both multi-threaded and single threaded, for use in a DLL or
in the main, with or without the Boehm collector, etc., etc.
--
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