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. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost