C++ class member name lookup issues (regarding the wording of standard n3225)

Question

I am very confused about the standard 10.2/13,

[ Note: Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be ambiguous (4.11, 5.2.5, 5.3.1, 11.2).—end note ] [ Example:

struct B1 {
  void f();
  static void f(int);
  int i;
};
struct B2 {
  void f(double);
};
struct I1: B1 { };
struct I2: B1 { };
struct D: I1, I2, B2 {
  using B1::f;
  using B2::f;
  void g() {
    f(); // Ambiguous conversion of this
    f(0); // Unambiguous (static)
    f(0.0); // Unambiguous (only one B2)
    int B1::* mpB1 = &D::i; // Unambiguous
    int D::* mpD = &D::i; // Ambiguous conversion
  }
};

I cannot see why this is unambiguous int B1::* mpB1 = &D::i; // Unambiguous

Visual C++, Gcc and CLang all say that it is ambiguous access to D::i!

The wording seems to be related to the core issue #39 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#39, and the final proposal is here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1626.pdf

I now find that the new algorithm-based wordings (10.2/3-10.2/6) are even more confusing because none of the note in 10.2/9, 10.2/10, 10.2/11, and 10.2/13 fully complies to 10.2/3-10.2/6. I can take 10.2/9-10.2/11 as exceptions, but I am especially confused about 10.2/13. I have no idea on the intention of 10.2/13.

How should the example in 10.2/13 be looked-up according to the 10.2/3-10.2/6? What's the intention of 10.2/13, i.e., what's the situation that 10.2/13 is considered as an exception of 10.2/3-10.2/6?

Please give me some hints. Thank you very much.

---

After some thinking, I think the intention of 10.2/13 is clearer to me.

int B1::* mpB1 = &D::i; // Unambiguous

This should be unambiguous and the current compilers are wrong on this. This is unambiguous because pointer to class members initialization doesn't involve in accessing the object yet.

int D::* mpD = &D::i; // Ambiguous conversion

This actually means when convert from int B1::*mpB1 to int D::*mpD, the conversion is ambiguous due to ambiguous base classes.

Answer 1

For the B1::* case, the interpretation is unambiguous, simply being the offset from the start of B1 to i.

In 5.3.1/3:

struct A { int i; };
struct B : A { };
... &B::i ... // has type int A::*

So the trick is to make &D::i be of type B1::* in the first place. Then:

int B1::* mpB1 = &D::i; // Unambiguous

is simple. The interest then comes in:

int D::* mpD = &D::i; // Ambiguous conversion

Here the RHS is of type B1::* and needs a conversion as we need to determine which base is being referred to.

Answer 2

This:

int B1::* mpB1 = &D::i; // Unambiguous

Is unambiguous because the result is being assigned to a pointer to member of class B.
So it don't matter which i is chosen as the offset is relative to a B member (not the parent D class).

So it is unambiguous to you and me but I don't think the compiler can handle it.

Answer 3

A quick check on ISO IEC 14882 2003 Section 10 does not have this example, or anything similar to this. C++0x is draft standard, and VC++/GCC/CLang are not compliant to it.

My Guess: This is some byproduct of the new auto typing and not found in older C++ standard.

Answer 4

FWIW, I'm copying over my answer I gave to the usenet copy of this question:

Hi all,
 
I am very confused about the standard n3225 10.2/13,  
[ Note: Even if the result of name lookup is unambiguous, use of a name found in multiple subobjects might still be ambiguous (4.11, 5.2.5, 5.3.1, 11.2).—end note ] [ Example:  

struct B1 {
  void f();
  static void f(int);
  int i;
};
struct B2 {
  void f(double);
};
struct I1: B1 { };
struct I2: B1 { };
struct D: I1, I2, B2 {
  using B1::f;
  using B2::f;
  void g() {
    f(); // Ambiguous conversion of this
    f(0); // Unambiguous (static)
    f(0.0); // Unambiguous (only one B2)
    int B1::* mpB1 = &D::i; // Unambiguous
    int D::* mpD = &D::i; // Ambiguous conversion
  }
};

I cannot see why this is unambiguous int B1::* mpB1 = &D::i; // Unambiguous  

&D::i has type int B1::*, and unambiguously refers to data member i of  B1. If you dereference it with a D object or if you assign it to a int  D::*, you will get an ambiguity as needed. 

Visual C++, Gcc and CLang all say that it is ambiguous access to D::i!  

None of those compilers implement 10.2 yet. 

The wording seems to be related to the core issue #39 http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#39, and the final proposal is here: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1626.pdf   I now find that the new algorithm-based wordings (10.2/3-10.2/6) are even more confusing because none of the note in 10.2/9, 10.2/10, 10.2/11, and 10.2/13 fully complies with 10.2/3-10.2/6. I can take 10.2/9-10.2/11 as exceptions, but I am especially confused about 10.2/13. I have no idea on the intention of 10.2/13.  

You need to give examples that show what you don't understand. 

How should the example in 10.2/13 be looked-up according to the 10.2/3-10.2/6? What's the intention of 10.2/13, i.e., what's the situation of which 10.2/13 is considered as an exception of 10.2/3-10.2/6?  

The new algorithm based lookup rules decouples runtime concerns (finding an  unique object) from compile time/lookup concerns (finding a declaration that  a name refers to). 

The following is well-formed with the new wording:

struct Z { int z; };
struct X : Z { };
struct Y : Z { };
struct A : X, Y { };

struct B : A {
  using A::z;
};

The declaration using A::x; introduces a member name into B that refers to  the declaration Z::z. In a declarative context, this is perfectly fine. An  error is risen only when you access B::z as a member access expression  (5.2.5). 

Don't feel bad about having mistaken this about the member pointer case. I did so too in the past, and the corresponding issue report actually made it into a C++0x draft. They luckily changed it back when they noticed that change was wrong.