From: Iain K.Hanson (iain.hanson_at_[hidden])
Date: 2002-10-09 12:23:39
> [mailto:boost-bounces_at_[hidden]]On Behalf Of David Abrahams
> Sent: 09 October 2002 17:21
> "Eric Woodruff" <Eric.Woodruff_at_[hidden]> writes:
> > How do you get the notion of it being undefined?
> I never said anything was undefined. I said the behavior of
> reinterpret_cast was implementation-defined.
> > The standard says:
> > "7 A pointer to an object can be explicitly converted to
> a pointer to an
> > object of different type."
> > Then it seems to say that you cannot convert from T* to T2*
> then back to T*
> > and expect it to be defined--but we are not doing that.
> You can't count on any particular behavior if you use reinterpret_cast
> for anything, unless you read the compiler manual first.
> Wow, this seems really difficult to grasp, but I can't understand why.
> 5.2.10 Reinterpret cast
> 3 The mapping performed by reinterpret_cast is
> implementation-defined. [Note: it might, or might not, produce a
> representation different from the original value. ]
> That means it does _something_, but only the compiler vendor and those
> who have read the manual know what it does.
Just to add to that, pointer bit patterns are hardware, o/s, and compiler
vendor dependant. I.e iirc on vax vms with dec C compiler, the null pointer
was implemented as an alternating bit pattern of zeros and ones. This was
for detection of null pointer de-reference.
To quote from stroustrup 3e original edition, section 10.4.11 ( page 256
in my copy ) ( less definative than the standard but probably more
"The reinterpret_cast is the crudest and potentially nastiest of the type
conversion operators (s6.2.7). In most cases, it simply yields a value with
the same bit pattern as its argument with the type required. Thus, it can be
used for the inherently implementation-dependant, dangerous, and
absoutely necessary activity of converting integer values to pointers and
For a fully explanation see section 6.2.7 in the same book.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk