Re: STL objects and binary compatibility
On May 13, 7:27 pm, Paavo Helde <nob...@ebi.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote in news:b1725b32-e4b6-43d1-
8be1-33277dd12...@y38g2000hsy.googlegroups.com:
On May 13, 1:35 am, Paavo Helde <nob...@ebi.ee> wrote:
James Kanze <james.ka...@gmail.com> wrote
innews:af6d7bb2-944e-4e8d-87eb-a74731b9f7ad@
27g2000hsf.googlegroups.com:
On 12 mai, 08:15, Paavo Helde <nob...@ebi.ee> wrote:
[concerning the _SECURE_SCL option in VC++...]
[...]
VC++ on XP crashes the application with the message "test.exe
has encountered a problem and needs to close. We are sorry
for the inconvenience.". If _SECURE_SCL is defined to 0, the
program runs nicely and produces the expected results.
By shear chance, maybe. It's definitly something that you
shouldn't be doing.
Example 2:
#include <vector>
#include <iostream>
#include <ostream>
double summate(const double* arr, size_t n) {
double sum=0.0;
for(size_t i=0; i<n; ++i) {
sum += arr[i];
}
return sum;
}
int main() {
std::vector<double> v;
// ...
std::cout << summate(&v[0], v.size()) << "\n";
}
This fails in the similar fashion, but only on an important
customer demo, where the size of array happens to be zero.
And? It's undefined behavior, and there's no reason to expect
it to work.
It appears that VC++ is warning me against potential problems
which might happen on exotic hardware (or on common hardware
in exotic modes), but does this on the most unpleasant way,
crashing on run-time the application which would have run
nicely otherwise.
Or not. It certainly wasn't guaranteed to run nicely.
Programming is kind of engineering. In engineering you have to
make trade-offs in order to achieve your goals. Here, in this
case I have a large application which may contain UB similar
to above cases. I have tried hard to find and fix all UB, but
one never can be sure. The UB of the above sort does arise
only if the size of vector is zero, which usually does not
happen. The code is complex and I'm not sure all corner cases
are correctly covered by unit tests. In other words, I believe
that the code is correct, but I am not 100% sure.
That's one of the nice things about UB:-). You can never be
100% sure.
Now I have to deliver the final application (Release mode) to
the customer. The question is whether to keep the checked
iterators feature on or not. I have the following choices:
a) Keep the checked iterators on: this makes the program
somewhat slower, and if a corner case of this UB is
encountered, the probability of a customer support problem
appearing is 100%.
b) Switch them off: the code is faster, and if this corner
case of UB is encountered, the probability to have a customer
support problem is below 100% (0% by empiric evidence, but I
will not stress that). The probability of producing slightly
wrong results is somewhat higher than 0, but also close to
zero by my estimation, as the operation involved in UB case
most probably does not write anything to memory.
Of course, the decision also depends on the application
domain. In a safety-critical work you cannot live on
probabilities. In our case my favorite is clearly b).
Maybe. You explain a bit more about the commercial context
later, which may mean that you don't really have much choice.
Cite fromhttp://msdn.microsoft.com/en-us/library/aa985965.aspx
"Checked iterators apply to release builds and debug builds.
...
Maybe, but I manage to turn them off or on at will. (I
currently have them turned on in both release and debug builds,
at least at present, but I rather suspect that I'll change this
policy in the long. Basically, I use a common build for both
release and debug, and offer an "optimized" build for the
special cases where performance is an issue. And it does make
sense to turn them off in the optimized build.)
Of course they can be turned off. In an earlier message in
this thread you said: "Any code which does anything with them
(_GLIBCXX_DEBUG and _SECURE_SCL) is invoking undefined
behavior." Or do you want to claim it is not UB if specified
on command-line?
Well, most correctly: an implementation may define undefined
behavior. If you conform to the "definitions" in the
documentation, you're OK. I had simply supposed that the
documentation would say to define it on the command line,
because it seems to be the only thing which makes sense.
Judging from the little bit you quoted, however, there seems to
be a problem in the documentation as well. (I'm pretty sure
that *if* you use a #define in the code, it has to be before any
of the includes. Personally, I think it easier to manage
this---and the potential portability issues---by putting it in
the command line.)
(Technically, of course, the command line is implementation
defined, totally. But I don't want to get into playing word
games.)
The default value for _SECURE_SCL is 1, meaning checked
iterators are enabled by default."
The default value is only used if _SECURE_SCL hasn't been
previously defined. If I invoke VC++ with -D_SECURE_SCL=0,
there's no checking.
Yep, that's what the word "default" means.
Yes. And the fact that it is a "default" generally implies that
other values are possible. Whether you use it or not is up to
you.
[...]
All modules exchanging dynamically allocated objects should
better be linked to the same run-time library - if the choice
is not the default one it is very hard to achieve. And by
abandoning the debug library one abandons also the debugging
features it offers.
But all objects will be linked to the same run-time library,
since you only link once. I think you're confusing issues
I have about 20-30 different DLL-s, which are all first linked
once when they are built, and loaded in the running
application dynamically when needed, thus completing the
linking process. Different DLL-s may well happen to be linked
to different runtime libraries (as is the case for static libs
as well, but this can be controlled much better).
Because you do the linking:-). In general, avoid DLL's unless
they are absolutely necessary, because you don't know what
you're going to get. However...
[...]
At any rate, I've just verified: /D_SECURE_SCL=0 in the command
line does the trick. But you very definitely must be sure that
all of the code using your library is compiled with this option.
If you're selling a library to outside customers, this could be
considered a very constraining requirement.
We are selling a complete application containing many
libraries. In principle the customer can develop and add their
own libraries. OTOH, they can also create custom applications
using our libraries. Yes, it might be appropriate to offer
different versions. However, as you can see we have hard times
sometimes even to get the single version consistent...
So your commercial constraints say you need the DLL's. And
binary compatilibity with code which you don't control. It's a
difficult problem, since you really don't have any control over
what the customer does. At the very least, however, I think you
have to deliver two versions, corresponding to the two default
command lines that Visual Studio uses. (Not that these
default's are really useful for anything, but a lot of people
will probably use them.) Beyond that, I can well see an
interest in providing other versions as well. The problem is,
of course, documenting this, and getting your customers to
manage it correctly. I'm not familiar enough with the Windows
world to make any concrete suggestions, but under Unix, I'd
start by putting each version in a separate directory, and very
carefully documenting the compiler flags which can't be changed
for each, probably providing a set of script files which can be
sourced to define shell variables to be used when invoking the
compiler (or in the makefile). This also would work for me
under Windows, but I'm pretty sure that I'm not a typical
Windows developer. (I use bash/vim/GNU make, rather than Visual
Studios:-).) I don't know how you'd integrate this so it would
be easy to import under Visual Studios (but I rather suspect
that finding a way is a commercial necessity for you).
--
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