"David B. Held" <[EMAIL PROTECTED]> writes: | "Gabriel Dos Reis" <[EMAIL PROTECTED]> wrote in message | [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... | > David Abrahams <[EMAIL PROTECTED]> writes: | > | > | [...] | > | if is_pointer<source_type> and is_pointer<dest_type> | > | return (dest_type)( | > | (unisgned)src | > | ^ sizeof(remove_pointer<source_type>::type) | > | ^ sizeof(remove_pointer<dest_type>::type)); | > | > And why isn't that applicable to the trip | > | > char* -> void* -> Foo* | | First of all, because that trip with reinterpret_cast<> is even more | implementation-defined than char* -> Foo*.
1) that trip is what used in dangerous_cast<> 2) no, I was not talking of that trip with reinterpret_cast<>; yes, I was talking of dangerous_cast<>. 3) Either something is implementation-defined or it is not; the mapping of reinterpret_cast<> is implementation-defined. There is no notion of being "more implementation-defined" :-) | Second, because that | trip isn't even being proposed for reinterpret_cast<>, it's being | proposed for static_cast<>. That is exactly what I was talking about. | And third, Dave's "perverse | implementation" only applies to reinterpret_cast<>, not | static_cast<>. The question is why reinterpret_cast : char* -> T* can be perverse and not char* -> void* -> T* // arrow mapped by static_cast<>? That was the content of my question. | For the static_cast<> trip, consider: | | 4.10 Pointer conversions | | 2 An rvalue of type "pointer to cv T," where T is an object | type, can be converted to an rvalue of type "pointer to cv | void." The result of converting a "pointer to cv T" to a "pointer | to cv void" points to the start of the storage location where the | object of type T resides, as if the object is a most derived | object (1.8) of type T (that is, not a base class subobject). | | char* -> void* OK. | and | | 5.2.9 Static cast | | 10 An rvalue of type "pointer to cv void" can be explicitly | converted to a pointer to object type. A value of type pointer | to object converted to "pointer to cv void" and back to the | original pointer type will have its original value. | | void* -> Foo* OK. Please do note that the Standard says *nothing* about the meaning of derefencing the resulting pointer. Do notice how it actually takes special disposition to say that the sequence T* -> void* -> T* is the identity. Leaving the possibility that U* -> void* -> T* may just get you in the outer space. | Note that "implementation defined" and "undefined" do not | appear in either of those paragraphs. Maybe the standard | is not sufficiently clear to determine whether char* -> void* -> | Foo* has the intended effect. However, that seems to be a | legal reading of it. 1.3.12 [...] Undefined behavior may also be expected when this International Standard omits the description of any explicit definition of behavior. -- Gaby _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
