Re: std::copy implementation standard conforming?
Bart van Ingen Schenau wrote:
Andrei Alexandrescu (See Website For Email) wrote:
So by the letter of the standard, by the time the arguments have
reached std::copy, the size information has been lost by necessity.
That last statement is simply untrue.
There is nothing in the standard that forbids an implementation to
use 'fat' pointers, which keep size information.
After the array to pointer conversion, size information is no longer
required to be present, but you can't say that it must be absent.
You're right. Let's note that the discussed implementation does not do
that, instead it takes that information from the static type. My reading
of the standard is that the implementation is not allowed to do so. The
argument goes like this: std::copy takes an OutputIterator, T[2] is not
an output iterator => std::copy can't get its little dirty hands on T[2]
and consequently on the 2 in it.
But, I get your point: we could assume that std::copy gets the 2 through
other, occult means.
Now it would be a tad more tedious to prove that writing b[3] is legal
and same as a[1][0], but I'm sure it can be done. (I tried by quickly
overseeing section 3.7 to 3.9, without success.)
That would be very tedious indeed, because according to my
interpretation of the standard, writing b[3] causes UB due to accessing
an array object outside its declared bounds. (sections 8.3.4 and 5.7)
The thing is that b is not an array object. It's a reference to a
fragment of a larger array object. My whole point is that the read and
write of b[2] (sorry for the confusing b[3] in my previous post) is
dynamically correct because the actual memory laying there indeed exists
and is statically typed as a float when accessed via the actual object a.
I understand what the checked STL routines are trying to do. All I'm
saying is that, in addition to incorrect code that they disallow, they
also disallow correct code. I agree that the correct code they
disallow is often of questionable quality, but it is 100% correct code
by the letter of the standard.
Although the program logic makes it clear that the access is 'safe' and
most implementations do 'the right thing', to my knowledge it is
actually UB and therefor not 100% conforming code.
Well, at best you'd prove that :o). None of us have come with a proof
either way.
There is a reason why the code that started this tread is commonly known
as the 'struct hack' and that C99 has some special syntax and semantics
for these kinds of structures.
People do disagree on this, but there are enough well respected experts
on both sides to label the actual validity of the code as questionable.
Who? Where?
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.
Probably we use different meanings for the term "correct". By figuring
out if a piece of code is _correct_ within this discussion, my
definition is: go to the standard and figure if it defines the effects
of said code. It's as cut and dried as it gets.
And what if the standard is open to interpretation on the issue?
Then we'd all be right!
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]