Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* Kai-Uwe Bux:
Alf P. Steinbach wrote:
* Rolf Magnus:
[snip]
Actually, the exception covers not only typeid, but also sizeof:
"An expression is potentially evaluated unless either it is the
operand of the sizeof operator (5.3.3), or it is the operand of the
typeid operator and does not designate an lvalue of polymorphic class
type (5.2.8)."
No, that isn't the exception that applies to typeid.
And no, it doesn't matter whether a dereferencing is potentially
evaluated or not.
That sounds like a defect. Would you please give chapter and verse on
this one.
The typeid defect is being addressed, but the proposed resolution is to
allow null-pointer dereferencing in general; see typeid.
Do you know the number of the defect report?
No, sorry, I don't recall, execpt that it isn't about typeid per se;
it's about nullpointer dereferencing and one-past-array access.
Hey, wait a minute, I had some correspondence about that.
[searching inbox...]
OK, "CWG 232", that's from correspondence related to a comp.std.c++
thread titled "Are references to not-quite-objects legal?", late 2005.
Probably that's the one; it's at <url:
http://std.dkuug.dk/jtc1/sc22/wg21/docs/cwg_active.html#232>.
It's a bit funny because it starts out noting the current wording of the
standard (UB), then goes on to discuss original intent, and concludes
that all's OK because of the intent -- which it definitely isn't,
since otherwise that DR wouldn't have existed.
The nullpointer dereferencing no matter runtime evaluation or not is
because nullpointer dereferencing is stated (twice) as undefined
behavior without reference to runtime or compile time evaluation.
Could you point me to those two clauses in the standard.
The first one is the definition of "undefined behavior". :-)
1.3.12. Your original claim was:
failed. Could you please provide a reasoning that is a little more detailed