From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 698 invoked by alias); 1 Feb 2002 15:36:05 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 633 invoked by uid 71); 1 Feb 2002 15:36:02 -0000 Date: Fri, 01 Feb 2002 07:36:00 -0000 Message-ID: <20020201153602.632.qmail@sources.redhat.com> To: jason@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Reichelt Subject: Re: c++/2127: namespace problems Reply-To: Reichelt X-SW-Source: 2002-02/txt/msg00015.txt.bz2 List-Id: The following reply was made to PR c++/2127; it has been noted by GNATS. From: Reichelt To: jason@redhat.com Cc: Subject: Re: c++/2127: namespace problems Date: Fri, 1 Feb 2002 16:26:22 +0100 Hello again, On 1 Feb, you wrote wrote: >>> This is not a bug. The candidates considered for the == expression in dummy >>> are those visible at the point of definition of dummy (only the S1 >>> version) and those in the associated namespace of S2 (also only >>> the S1 version). You must move the S2 version into the namespace. > me> I'm not quite convinced, because the code compiles fine, if you remove me> the first version of the == operator (the S1-version inside the me> namespace). According to your explanation the code shouldn't compile me> in this case. > > No, it shouldn't, but g++ doesn't implement 2-phase name lookup properly. > me> The only thing that might be possible IMHO is that the definition me> outside the namespace is shadowed by the one inside > > That is indeed what is happening in g++ currently. It does a normal lookup > in the scope of the function, which finds the S1 version and stops. Ok, you win ;-) By the way, SGI's native compiler (which has some problems with template lookup, it doesn't do Koenig-lookup for example) accepts the code, whereas Comeau's online compiler rejects the code. Greetings, Volker Reichelt