Re: STL objects and binary compatibility
James Kanze <james.kanze@gmail.com> wrote in news:b1725b32-e4b6-43d1-
8be1-33277dd1279a@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.
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).
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?
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.
[...]
And no, this is not simpler. For starters, VC++ wizards
generate code (can be deleted of course) to redefine the "new"
keyword in Debug builds, which would cause link errors when
attempting to link to the Release-build run-time library.
In other words, no one in his right mind uses the wizards.
Because the last thing you want is funny things happening with
your keywords.
Agreed.
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).
somewhat: what you mean, I think, is that all of the modules
must be compiled with the same options (at least with regards to
those which can affect binary compatibility), and that the
application must then be linked with a run-time library which
was also compiled with those options.
Yes, that's easy, but this goes only for a single DLL.
Compared with the simplicity and flexibility of the Linux/ELF
dynamic linking process (cf. libefence) it's a shame. I know
your answer - use static linking and monolithic applications.
Unfortunately this is not always an option.
Not always, I know. And when it's not, I've run into exactly
the same problem under Linux, with g++. For that matter, I've
run into it when statically linking as well---the problem is
really independent of whether you link statically or
dynamically. If sizeof( std::vector<double> ) is 12 in the
calling function, and 28 in the library routine which receives a
reference to it, problems will ensue.
Right.
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...
Regards
Paavo