From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-12-07 11:17:20
"Gabriel Dos Reis" <gdr_at_[hidden]> wrote in message
> "Eric Woodruff" <Eric.Woodruff_at_[hidden]> writes:
> | > Thus, given that h.storage is properly aligned, (which is the purpose
> | the
> | > other union member), after "new(h.storage) Foo", h.storage contains a
> | > object. Thus accessing it through a pointer-to-Foo is legal, as Foo is
> | > dynamic type of the object.
> | >
> | This is precisely my reasoning why reinterpret_cast<> is _not_
> | implementation defined.
> | It must be the case that it is equal to the situation of having
> | Foo* -> char */void* -> Foo* if Foo is the dynamic type of the object.
> After giving more thoughts to the analysis given by Anthony and
> 5.2.10/1, I think I agree with you're right.
Well, for a reinterpret_cast to be valid, it must be used to cast away from
the type, and return to it. In my example, I was only returning to it. I
question the validity of that. If new (p) Object; takes a void* and does an
implicit cast, I don't think there is any reinterpret_casting taking place
on the inside. However, I think there must be some kind of cast to char* to
allocate the memory in number of bytes, but I'm not sure. The size of char
is not necessarily 1 byte, correct? So either way, this allocation
implementation defines what happens.
Again, however, I mentioned in a different post that we could always force a
reinterpret_cast<> via new (reinterpret_cast<void*> (h.storage)) Object, but
if an implementation remembers that h.storage is an unsigned char*, or even
if it doesn't, I think reinterpret_cast may only be valid to cast void*
h.storage to unsigned char* h.storage.
This is, of course, because of the wording of the standard. In reality,
reinterpret_cast<> most likely has the expected result on all platforms.
> -- Gaby
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk