From: Gabriel Dos Reis (gdr_at_[hidden])
Date: 2002-12-04 15:57:19
"David B. Held" <dheld_at_[hidden]> writes:
| "Gabriel Dos Reis" <gdr_at_[hidden]> wrote in message
| > David Abrahams <dave_at_[hidden]> 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
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*
| 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.
[...] Undefined behavior may also be expected when this International
Standard omits the description of any explicit definition of
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk