Re: std::copy implementation standard conforming?
Greg Herlihy wrote:
On the other hand, if the program's call to std::copy() does copy objects
beyond the bounds of the destination array, then all bets are off. The
program's behavior becomes at that point, undefined. Therefore the
implementation has no obligation to adhere to its previous behavior (and in
fact it does not - instead it helpfully crashes as designed).
The code is 'illegal' because it is forbidden to overload templates in
namespace std. But if forced to use this 'illegal' code then the
workaround is to cast to a byte *, or create a temp byte * and use it.
This will remove the 'illegal' overload from consideration.
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.
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.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]