Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > class member name lookup issues

Reply
Thread Tools

class member name lookup issues

 
 
ZMZ
Guest
Posts: n/a
 
      01-20-2011
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

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/wg...efects.html#39, and
the final proposal is here: http://www.open-std.org/jtc1/sc22/wg...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.

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?

Please give me some hints. Thank you very much.
 
Reply With Quote
 
 
 
 
Johannes Schaub (litb)
Guest
Posts: n/a
 
      01-20-2011
ZMZ wrote:

> 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/wg...efects.html#39, and
> the final proposal is here:
> http://www.open-std.org/jtc1/sc22/wg...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:;" introduces a member name into A 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).

There is currently a confusion about using declarations in general though,
in my opinion. A using declaration introduces a new member name into a
scope. Name lookup looks through the using declaration, but some paragraphs
in the spec assumes it doesn't (overload resolution in particular). A second
problem, in my opinion, is that 10.2p3 says "type declarations are replaced
by the types they designate". That doesn't make sense: "typedef int type;"
what will a lookup for "type" yield?

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
qualified member name lookup vanyacpp@gmail.com C++ 3 09-18-2012 07:05 AM
member name lookup Fraser Ross C++ 3 12-20-2007 05:58 PM
Nested Class, Member Class, Inner Class, Local Class, Anonymous Class E11 Java 1 10-12-2005 03:34 PM
Can Derived class static member access protected member from base class? Siemel Naran C++ 4 01-12-2005 06:46 PM
Cannot refer to an instance member of a class from within a shared method or shared member initializer without an explicit instance of the class. DJ Dev ASP .Net 3 02-08-2004 04:19 PM



Advertisments