From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1888 invoked by alias); 10 Sep 2002 06:37:40 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1870 invoked from network); 10 Sep 2002 06:37:40 -0000 Received: from unknown (HELO localhost.localdomain) (64.134.74.101) by sources.redhat.com with SMTP; 10 Sep 2002 06:37:40 -0000 Received: from warlock.codesourcery.com (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g8A6ZW312578; Mon, 9 Sep 2002 23:35:33 -0700 Date: Mon, 09 Sep 2002 23:37:00 -0000 From: Mark Mitchell To: Matt Austern , Wolfgang Bangerth cc: "gcc@gcc.gnu.org" Subject: Re: Ambiguous base class Message-ID: <31460000.1031639730@warlock.codesourcery.com> In-Reply-To: <6B98C701-C1E4-11D6-A346-000393B2ABA2@apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SW-Source: 2002-09/txt/msg00351.txt.bz2 > Again, here is my example: > struct A { int x; }; > struct B1 : public A { }; > struct B2 : public A { }; > struct D : public B1, public B2 { }; > > int f(D d) { > return d.B1::A::x; > } I looked at this in the standard recently (in connection with the new parser) -- but I don't remember what I read. What I do remember is that you're supposed to look at "B1::A::x" as two pieces: a nested-name-specifier (B1::A::) and an unqualified name. You resolve the nested-name-specifier to a class or namespace; in this case "A". You then look for "x" in "A", and you can use "A" to disambiguate things, but "B1" is lost to you at this point. In other words, your case is no different than if you add in: struct Z { typedef A ZA; }; return d.ZA::x; Now, I do wish I remembered what lead me to this conclusion... (FYI, EDG 3.0 rejects your test case as well.) -- Mark Mitchell mark@codesourcery.com CodeSourcery, LLC http://www.codesourcery.com