This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Voted into the WP at the February, 2012 meeting;moved to DR at the October, 2012 meeting.]
An lvalue referring to an out-of-lifetime non-POD class objects canbe used in limited ways, subject to the restrictions in6.8.4 [basic.life] paragraph 6:
if the original object will be or was of a non-POD class type, theprogram has undefined behavior if:
the lvalue is used to access a non-static data member or call anon-static member function of the object, or
the lvalue is implicitly converted (7.3.12 [conv.ptr])to a reference to a base class type, or
the lvalue is used as the operand of astatic_cast(7.6.1.9 [expr.static.cast]) except when the conversion isultimately tocvchar& orcvunsignedchar& ), or
the lvalue is used as the operand of adynamic_cast(7.6.1.7 [expr.dynamic.cast]) or as the operandoftypeid.
There are at least a couple of questionable things in this list.First, there is no “implicit conversion to a reference to abase class,” as assumed by the second bullet. Presumablythis is intended to say that the lvalue is bound to a reference toa base class, and the cross-reference should be to9.5.4 [dcl.init.ref], not to 7.3.12 [conv.ptr](which deals with pointer conversions). However, even given thatadjustment, it is not clear why it is forbidden to bind a referenceto a non-virtual base class of an out-of-lifetime object, as that isjust an address offset calculation. (Binding to a virtual base, ofcourse, would require access to the value of the object and thuscannot be done outside the object's lifetime.)
The third bullet also appears questionable. It's not clear whystatic_cast is discussed at all here, as the onlypermissiblestatic_cast conversions involving reference typesand non-POD classes are to references to base or derived classes andto the same type, modulo cv-qualification; if implicit“conversion” to a base class reference is forbidden in thesecond bullet, why would an explicit conversion be permitted in thethird? Was this intended to refer toreinterpret_cast? Also, is there a reason to allow chartypes but disallow array-of-char types (which are more likely to beuseful than a single char)?
Proposed resolution (March, 2008):
Change 6.8.4 [basic.life] paragraph 5 as follows:
...If the object will be or was of a non-trivial class type,the program has undefined behavior if:
the pointer is used to access a non-static data member orcall a non-static member function of the object, or
the pointer is implicitly converted (7.3.12 [conv.ptr]) to a pointer to avirtual base class
type, orthe pointer is used as the operand of astatic_cast(7.6.1.9 [expr.static.cast])
(except when the conversion istovoid*, or tovoid* and subsequently tochar*, orunsigned char*).pointer tocvvoid, or to pointer tocvvoid andsubsequently to pointer tocvchar or pointer tocvunsigned char, orthe pointer is used as the operand of adynamic_cast(7.6.1.7 [expr.dynamic.cast])...
Change 6.8.4 [basic.life] paragraph 6 as follows:
...if the original object will be or was of a non-trivialclass type, the program has undefined behavior if:
the lvalue is used to access a non-static data member orcall a non-static member function of the object, or
the lvalue is
implicitly converted (7.3.12 [conv.ptr])bound to a reference to avirtualbase classtype(9.5.4 [dcl.init.ref]),or
the lvalue is used as the operand of astatic_cast (7.6.1.9 [expr.static.cast]) except when theconversion is ultimately tocvchar& orcvunsigned char&, orthe lvalue is used as the operand of adynamic_cast (7.6.1.7 [expr.dynamic.cast]) or as theoperand oftypeid.
[Drafting notes: Paragraph 5 was changed to track thechanges to paragraph 6. See also the resolution forissue 658.]