RE: [boost] Re: reinterpret_cast<constshared_ptr<constT>&>[wasRe:const-correctness as function argument]

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
accessable):

"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
occasionally
absoutely necessary activity of converting integer values to pointers and
vice
versa."

For a fully explanation see section 6.2.7 in the same book.

/ikh