[ note: Forwarded to C++ Committeel -sdc ]
Is reinterpret_cast<T*>(null_pointer_constant) guaranteed to yield the
null pointer value of type T*?
I think a committee clarification is needed. Here's why: 5.2.10
[expr.reinterpret.cast] par. 8 talks of "null pointer value", not
"null pointer constant", so it would seem that
is a normal int->T* conversion, with an implementation-defined result.
However a little note to 5.2.10 [expr.reinterpret.cast] par. 5 says:
Converting an integral constant expression (5.19) with value zero
always yields a null pointer (4.10), but converting other
expressions that happen to have value zero need not yield a null
Where is this supported in normative text? It seems that either the
footnote or paragraph 8 doesn't reflect the intent.
PROPOSED RESOLUTION: I think it would be better to drop the footnote
#64 (and thus the special case for ICEs), for two reasons:
a) it's not normative anyway; so I doubt anyone is relying on the
guarantee it hints at, unless that guarantee is given elsewhere in a
b) users expect reinterpret_casts to be almost always implementation
dependent, so this special case is a surprise. After all, if one wants
a null pointer there's static_cast. And if one wants reinterpret_cast
semantics the special case requires doing some explicit cheat, such as
using a non-const variable as intermediary:
int v = 0;
reinterpret_cast<T*>(v); // implementation defined
reinterpret_cast<T*>(0); // null pointer value of type T*
const int w = 0;
reinterpret_cast<T*>(w); // null pointer value of type T*
It seems that not only that's providing a duplicate functionality, but
also at the cost to hide what seems the more natural one.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:firstname.lastname@example.org ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.yqcomputer.com/