Re: std::copy implementation standard conforming?
On 6/23/07 3:06 AM, in article JK2sBF.AEt@beaver.cs.washington.edu, "Andrei
Alexandrescu (See Website For Email)" <SeeWebsiteForEmail@erdani.org> wrote:
Greg Herlihy wrote:
The entire reason for enabling "checked" routines in the first place - is to
find bugs (especially those that cause undefined behavior) in a C++ program.
Therefore, it makes little sense that once a checked routine does expose a
bug in the user program, to write code to bypass the checked routine - as if
concealing the bug somehow fixes it. (Moreover, checked routines are usually
enabled only in debugging builds anyway).
So the only sensible thing to do, in this situation (or any other situation
in which a program's undefined behavior has been made evident) - is not to
conceal or dispute the existence of the error - but to fix it.
But the entire point is that the code is not in error. The
implementation is in error (better said, overly conservative) by
assuming that the static type of the array faithfully represents its
dynamic length. This may not be the case in a variety of legal cases.
There is one that doesn't even have a cast in sight:
float a[5][2];
float (&b)[2] = a[0];
...
Copying into b would be legal for up to 10 floats, yet said
implementation would claim only 2 floats could be copied.
No. It is the user program - not the STL - that claims that "b" is a
reference to a two-float array. So, if the same program then proceeds to
copy ten floats into this supposedly two-float "b" array - then the
program's action is at odds with its own declaration. So there is a mistake
- either with the number of items being copied - or with the declared size
of b's array. And the purpose of a checked routine is simply to expose
contradictions like this one. In this example, the problem is fixed by
declaring "b" accurately:
float a[5][2];
float (&b)[10] = a;
Now, the merit of the implementation is that often code does keep the
static type of an object in sync with its dynamic extent. It's also true
that most often copying beyond the static length is an error. However,
staying with the letter of the law (and not its spirit), it can be said
that the STL implementation is in error and disallows code that is correct.
No, the "checked" STL routines seek to break incorrect code that happens to
work - while correct code is unaffected by their presence. After all,
type-unsafe operations - such as copying ten items into a array declared to
hold two - might work - but are clearly not correct in terms of C++'s type
system.
Now, there might seem to be little point in fixing errors in code that
works. But even though such errors might not affect the behavior of the
current program - they do pose a longer term risk to both the
maintainability and the modularity of the program and its code.
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]