Re: [boost] Re: Copy Constructible Concept

From: Douglas Gregor (gregod_at_[hidden])
Date: 2002-11-15 22:48:34

On Friday 15 November 2002 04:45 pm, Gennaro Prota wrote:
> Now, let me say that there's an explicit
> contradiction (as usual in such scenarios where a "special" case is assumed
> to be specified separately) between 5.2.10/10 and 5.2.10/7, because the
> latter says that in
>
>   reinterpret_cast<T*>(&x)
>
> you can only cast back the result to the source type, whereas 5.2.10/10
> defines the reference-cast in terms of pointer-cast and says it's ok to
> *dereference* the resulting value.

I don't see the contradiction here. 5.2.10/7 says that you can cast from a T 
pointer to a U pointer and back to a T pointer and get the original pointer 
back. 5.2.10/10 says that reinterpret_cast does the same for references (by 
specifying the semantics of reinterpret_cast on references in terms of 
reinterpret_cast on pointers). The dereference (and address-of, for that 
matter) operators are only there to perform the pointer/reference conversions 
to that the semantic equivalent can be specified.

If there's a contradiction between these two paragraphs, then there has to be 
some piece of code that can be interpreted in two different ways. Do we have 
such an example?

> However the real issue is that we have
> first
>
>   T -> cv char& -> char &
>
> and then
>
>   char * -> T*
>
> The latter is a reinterpret_cast from an rvalue of type char*, so except
> that I can cast it back to a char* the result is unspecified.

By 5.2.10/10, the first part of that is semantically equivalent to:

  T* -> cv char* ->char*

> In short, I agree with you that probably the intent is for it to work. But
> I think that should be clarified.
>
> Genny.

I've given probably the closest thing to a proof that one can get without 
having a formal specification. It uses only semantic equivalences given in 
the three paragraphs it cites. Is there a problem with it?

        Doug