Ambiguous pointer-to-member constant
Section [expr.unary.op]
Daniel Krügler

Created on 2009-10-19.00:00:00 last changed 143 months ago


Date: 2010-03-15.00:00:00

[Voted into WP at March, 2010 meeting.]

Date: 2009-10-15.00:00:00

Proposed resolution (October, 2009):

  1. Change [expr.unary.op] paragraph 3 as follows:

  2. ...For a qualified-id, if the member is a static member of type “T”, the type of the result is plain “pointer to T.” If the member is a non-static member of class C of type T, the type of the result is “pointer to member of class C of type T.,and the program is ill-formed if C is an ambiguous base (6.5.2 [class.member.lookup]) of the class designated by the nested-name-specifier of the qualified-id....
  3. Change 6.5.2 [class.member.lookup] paragraph 13 as follows:

  4. [Note: Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be ambiguous (7.3.13 [conv.mem], [expr.ref], [expr.unary.op], 11.8.3 [class.access.base]). —end note] [Example:...
Date: 2009-10-19.00:00:00

The resolution of issue 39 changed the diagnosis of ambiguity because of multiple subobjects from being a lookup error to being diagnosed where the result of the lookup is used. The formation of a pointer to member is one such context but was overlooked in the changes. [expr.unary.op] paragraph 3 should have language similar to [expr.ref] paragraph 5 and should be mentioned in the note in 6.5.2 [class.member.lookup] paragraph 13.

Date User Action Args
2010-03-29 00:00:00adminsetmessages: + msg2678
2010-03-29 00:00:00adminsetstatus: ready -> cd2
2009-11-08 00:00:00adminsetmessages: + msg2344
2009-10-19 00:00:00admincreate