This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 117b. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-08-11
1458. Address of incomplete type vs operator&()Section: 7.6.2.2 [expr.unary.op] Status: CD3 Submitter: Richard Smith Date: 2012-02-07[Moved to DR at the October, 2012 meeting.]
According to 7.6.2.2 [expr.unary.op] paragraph 5,
The address of an object of incomplete type can be taken, but if the complete type of that object is a class type that declares operator&() as a member function, then the behavior is undefined (and no diagnostic is required).
This should actually be “ill-formed, no diagnostic required” instead of undefined behavior, since the problem could be detected by whole-program analysis. Also, it's not clear what this means for constant expressions.
Proposed resolution (February, 2012):
Change 7.6.2.2 [expr.unary.op] paragraph 5 as follows:
The address of an object of incomplete type can be taken, but if the complete type of that object is a class type that declares operator&() as a member function, then the behavior is undefined (and no diagnostic is required). If & is applied to an lvalue of incomplete class type and the complete type declares operator&(), it is unspecified whether the operator has the built-in meaning or the operator function is called. The operand of & shall not be a bit-field.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4