On May 13, 1:35 am, Paavo Helde <nob...@[EMAIL PROTECTED]
> wrote:
> James Kanze <james.ka...@[EMAIL PROTECTED]
> wrote
> innews:af6d7bb2-944e-4e8d-87eb-a74731b9f7ad@[EMAIL PROTECTED]
> > On 12 mai, 08:15, Paavo Helde <nob...@[EMAIL PROTECTED]
> wrote:
> >> James Kanze <james.ka...@[EMAIL PROTECTED]
> wrote in
> >> news:1ca237c6-8137-4915-a076-
> >> a06dd96c2...@[EMAIL PROTECTED]
> > [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.
> Maybe I should have been more precise. The alarms are not
> "false" in the sense that the code has UB by the standard. On
> the other hand, the code appears to have defined meaning and
> guaranteed behavior by the same implementation which raises
> the alarms.
That is obviously false, since if it raises the alarm, it is
expressedly saying that the behavior isn't defined.
> Example 1:
> #include <vector>
> #include <iostream>
> #include <ostream>
> double summate(const double* from, const double* to) {
> double sum=3D0.0;
> for(const double* p=3Dfrom; p!=3Dto; ++p) {
> sum +=3D *p;
> }
> return sum;
> }
> int main() {
> std::vector<double> v;
> v.push_back(3.1415926);
> v.push_back(2.7182818);
> size_t n=3Dv.size();
> std::cout << summate(&v[0], &v[n]) << "\n";
> }
> In real life, summate() is some legacy function accepting
> double* pointers, which has to be interfaced with a new
> std::vector array used for better memory management. The
> expression &v[n] is formally UB.
Not just formally. I'm not aware of any implementation which
defines it.
> 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=3D0.0;
> for(size_t i=3D0; i<n; ++i) {
> sum +=3D arr[i];
> }
> return sum;
> }
> int main() {
> std::vector<double> v;
> // ...
> std::cout << summate(&v[0], v.size()) << "\n";
> }
> This fails in the similar fa****on, but only on an im****tant
> 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,
> cra****ng on run-time the application which would have run
> nicely otherwise.
Or not. It certainly wasn't guaranteed to run nicely.
> >> > 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.
> Providing the sources is out of question by company rules.
> Providing several versions is out of question because of lack
> of resources.
So you have to impose restrictions on the user. If they accept,
fine. If they prefer to find a different supplier who doesn't
impose such restrictions, that could be a problem.
> >> > 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.
> 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.)
> 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=3D0,
there's no checking.
> >> 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.
> Yes that's true in theory, but not in practice. It is possible
> to link with the run-time libraries meant for another build.
Certainly. You compile for one build, and you tell the compiler
to link with the libraries for another, and the compiler will do
exactly what you tell it to.
> 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.
> 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
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.
> 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.
Which brings us back to the start of the thread: binary
compatibility. Binary compatibility means not just using the
same version of the same compiler on the same platform, it also
means using the same compiler options, at least for some of
those 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 do***ented in the compilers' do***entation, so any
> >> code which uses them has implementation-defined behavior.
> > Yes, but doesn't the do***entation 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
> Cite fromhttp://msdn.microsoft.com/en-us/library/aa985896.aspx
> To enable checked iterators, set _SECURE_SCL to 1:
> #define _SECURE_SCL 1
> To disable checked iterators, set _SECURE_SCL to 0:
> #define _SECURE_SCL 0
Yuck. They really need to fix that. (What happens if you
define _SECURE_SCL to 0 after including <vector>?)
At any rate, I've just verified: /D_SECURE_SCL=3D0 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.
--
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
|
