Re: c++/2127: namespace problems

Re: c++/2127: namespace problems

[jason]

Synopsis: namespace problems

Responsible-Changed-From-To: unassigned->jason
Responsible-Changed-By: jason
Responsible-Changed-When: Fri Feb  1 04:03:32 2002
Responsible-Changed-Why:
    got it
State-Changed-From-To: analyzed->closed
State-Changed-By: jason
State-Changed-When: Fri Feb  1 04:03:32 2002
State-Changed-Why:
    This is not a bug.  The candidates considered for the == expression in dummy<S2> 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.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=2127

Re: c++/2127: namespace problems

[Reichelt]

The following reply was made to PR c++/2127; it has been noted by GNATS.

From: Reichelt <reichelt@igpm.rwth-aachen.de>
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<S2>
 >>> 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
 

Re: c++/2127: namespace problems

[Jason Merrill]

The following reply was made to PR c++/2127; it has been noted by GNATS.

From: Jason Merrill <jason@redhat.com>
To: Reichelt <reichelt@igpm.rwth-aachen.de>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/2127: namespace problems
Date: Fri, 01 Feb 2002 13:07:38 +0000

 >>>>> "Reichelt" == Reichelt  <reichelt@igpm.rwth-aachen.de> writes:
 
 >> This is not a bug.  The candidates considered for the == expression in dummy<S2>
 >> 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.
 
 > I'm not quite convinced, because the code compiles fine, if you remove
 > the first version of the == operator (the S1-version inside the
 > namespace). According to your explanation the code shouldn't compile
 > in this case.
 
 No, it shouldn't, but g++ doesn't implement 2-phase name lookup properly.
 
 > The only thing that might be possible IMHO is that the definition
 > 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.
 
 Jason

c++/2127: namespace problems

[reichelt]

>Number:         2127
>Category:       c++
>Synopsis:       namespace problems
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 28 12:16:00 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Volker Reichelt
>Release:        gcc version 3.0 20010227 (prerelease)
>Organization:
>Environment:
mips-sgi-irix6.5
>Description:
Compiling the following lines of code

namespace XXX {

struct S1 { int i; };
struct S2 { int i; };

bool operator == ( const S1&, const S1& ) { return true; }

template <class T> bool dummy ( const T &x ) { return x==x; }

}

bool operator == ( const XXX::S2&, const XXX::S2& ) { return true; }

void f () { XXX::S2 A; XXX::dummy(A); }


I get the error message

NamespaceBug.cpp: In function `bool XXX::dummy(const T&) [with T = XXX::S2]':
NamespaceBug.cpp:14:   instantiated from here
NamespaceBug.cpp:8: no match for `const XXX::S2& == const XXX::S2&' operator
NamespaceBug.cpp:6: candidates are: bool XXX::operator==(const XXX::S1&, const XXX::S1&)

Obviously the compiler fails to find the second operator ==.
Without namespaces or if one leaves out the first operator ==
everything works fine.
(gcc 2.95 shows the same behaviour, so this is not really a
regression. But because gcc 2.95 isn't so picky about the
namespace std, the code worked at least for XXX=std, whereas
gcc 3.0 fails for any namespace name.)
>How-To-Repeat:
g++ -c NamespaceBug.cpp
(assuming the file is named 'NamespaceBug.cpp')
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted: