[boost] Re: Copy Constructible Concept

From: Gennaro Prota (gennaro_prota_at_[hidden])
Date: 2002-11-16 12:24:19

Sorry for the late reply (it's just my timezone).

You wrote:
>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.

Unfortunately the standard is a great piece of work but fails
miserably to support you when you want to "deduce" things that are not
written explicitly there in plain English, especially when generic
expressions like "it's the same as", "is equivalent to", etc. are
used. I'll try to explain my point of view but I understand that it
can be quite boring for the subscribers of this list, especially if
they are not math fans. If you (plural) consider the reply off-topic
please let me know, possibly without overtones. I have replied anyway
(I mean despite the off-topicness) because I think Douglas is entitled
to have an answer. I did arise the question and he was kind enough to
reply. So should do I.

First of all the quotes:

   5.2.10/7: "A pointer to an object can be explicitly converted
   to a pointer to an object of different type.65) Except that
   converting an rvalue of type "pointer to T1" to the type
   "pointer to T2" (where T1 and T2 are object types and where
   the alignment requirements of T2 are no stricter than those
   of T1) and back to its original type yields the original pointer
   value, the result of such a pointer conversion is unspecified."

Incidentally, what does "converting back" means? However that's not
the main point.

   5.2.10/10: An lvalue expression of type T1 can be cast to the type
   "reference to T2" if an expression of type "pointer to T1" can be
   explicitly converted to the type "pointer to T2" using a
   reinterpret_cast. That is, a reference cast reinterpret_cast<T&>(x)
   has the same effect as the conversion *reinterpret_cast<T*>(&x)
   with the built-in & and * operators.

What does it mean "has the same effect of"? 5.2.10/7 says that the
result of reinterpret_cast<T*>(&x) is unspecified. What is the effect
of dereferencing it?

    *reinterpret_cast<T*>(&x)

The key point to understand my reluctance is that after I encounter
this violation of 5.2.10/7 I don't use it anymore during the "proof".
In other words, I consider it a proposition that has no role in this
deduction (otherwise I would use it only when it suites me). After
that, I go on up to the conversion to char&:

    T -> cv char& -> char &

At that point, I have another reinterpret_cast from a char* rvalue and
the best that I can find is that the result can only be converted back
(whatever that means) to char*.

[To be precise: in the reasoning about the reference casts I use only
the first part of /7: the part that says that a pointer... "can be
converted". I don't use the part concerning the resulting value]

>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.

In fact a simple change of the wording in /10 and/or/7 which clarified
that would satisfy me as far as addressof is concerned. Examples with
chain of casts would be welcome too.

[...]
>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?

Logically speaking my opinion is that yes, there's a problem. However
if everybody says there isn't I resign myself to your will, of course.

Genny.