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

From: Eric Woodruff (Eric.Woodruff_at_[hidden])
Date: 2002-11-20 15:58:31

"Rob Stewart" <stewart_at_[hidden]> wrote in message
news:200211202012.gAKKC9e24225_at_entwistle.systems.susq.com...
> From: "Eric Woodruff" <Eric.Woodruff_at_[hidden]>
> >
> > Every reference I can find excludes pointer conversions from being
> > implementation defined. They all (even the standard) specifically treat
> > pointer conversions differently (clause 7) than
pointer->integer->pointer
> > conversions. This is because creating an integer requires mapping the
bits
> > to a temporary, converting pointers does not require this because
pointers
> > share the same underlying representation, and it is done in compile time
so
> > there is no possibility of translation occuring.
> >
> > "reinterpret_cast treats all pointers exactly as traditional
type-casting
> > operators do. "
[snip]

> So, 5.2.10/7 plainly states that there's only one thing you can
> do portably with reintrepret_cast on pointers: convert from one
> type to another and back again.  Everything else is unspecified,
> so you can't even count on finding the result documented on each
> platform of interest.  This means that your references and
> understanding are wrong if they lead you to conclude that one-way
> pointer conversions are anything other than unspecified.
>
[snip]

The context surrounding converting a pointer "back again" is kind of
subjective. In the context of this original discussion, it was in converting
a pointer of an object to a char const* const for use with serialization.
This data is eventually deserialized and, thus, converted "back again."

In that context, do you find it to be unspecified? In my opinion, as long as
the bit representation remains the same [as in, the character bits are not
fiddled with during the time they are archived], it falls under the category
of converting a pointer to another pointer and then to the original type.