c++/8821: gcc 3.2 problem with overloaded inherited operator

c++/8821: gcc 3.2 problem with overloaded inherited operator

[andre]

>Number:         8821
>Category:       c++
>Synopsis:       gcc 3.2 problem with overloaded inherited operator
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 05 05:06:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Andre Mueller
>Release:        gcc version 3.2
>Organization:
>Environment:
Linux version 2.4.19-4GB
>Description:
A operator with a user class from a base class A will not 
be found if a derived class B overloads this operator.

> g++ tst.cpp
tst.cpp: In function `int main(int, char**)':
tst.cpp:16: no match for `B& << Z&' operator
tst.cpp:10: candidates are: void B::operator<<(int)
>How-To-Repeat:
class Z {   };

class A  {
public:
    void operator << ( const Z  & ) { }
};
  
class B : public A {
public:
    void operator << ( int ) {  }
}; 
  
int main( int , char ** ) {
    B   b;
    Z   z;
    b << z;     // Oops!? Why is it not possible to compile this?
    return 0;
}
>Fix:
An explicit downcast is necessary:
Replace the line
  b << z
with
 static_cast<A&>(b) << z;
>Release-Note:
>Audit-Trail:
>Unformatted:

Re: c++/8821: gcc 3.2 problem with overloaded inherited operator

[Wolfgang Bangerth]

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

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: andre@kiwisound.de, <gcc-bugs@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/8821: gcc 3.2 problem with overloaded inherited operator
Date: Wed, 11 Dec 2002 09:19:58 -0600 (CST)

 > > how operators behave. That's the question here. I concede that the 
 > > behavior is confusing.
 > First name lookup happens, once a name has been found, base classes
 > are not searched.
 > Then overload resolution happens
 > then accessibility is checked
 > 
 > This happens consistently regardless of virtuality or operatorness
 
 I was confused, sorry. (I guess mainly be the existence of 
 -Woverloaded-virtual, which suggests that virtual functions behave 
 differently.) Volker already pointed out the right paragraph of the 
 standard, and y'all are right, of course.
 
 Thanks for so bravely trying to enlighten me ;-)
   Wolfgang
 
 -------------------------------------------------------------------------
 Wolfgang Bangerth              email:           bangerth@ticam.utexas.edu
                                www: http://www.ticam.utexas.edu/~bangerth
 
 

Re: c++/8821: gcc 3.2 problem with overloaded inherited operator

[Nathan Sidwell]

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

From: Nathan Sidwell <nathan@codesourcery.com>
To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
Cc: andre@kiwisound.de, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: c++/8821: gcc 3.2 problem with overloaded inherited operator
Date: Wed, 11 Dec 2002 15:15:11 +0000

 Wolfgang Bangerth wrote:
  >andre wrote
 >>In my opinion it IS a bug because the operator of the parent class has
 >>another argument. So the name resolution should detect the matching
 >>operator in the parent class as usual in C++. I think overloaded
 >>operators should behave like overloaded functions (where the same thing
 >>works!).
 please post such code. It should not behave how you describe.
 
 > Note the distinction I made between overloaded functions and overloaded 
 > virtual functions. For some historical reason, a virtual function with a 
 > different argument list hides a function with the same name in the base 
 > class. This is not the case for non-virtual functions. I just don't know 
 hm, yes it is the same.
 
 > how operators behave. That's the question here. I concede that the 
 > behavior is confusing.
 First name lookup happens, once a name has been found, base classes
 are not searched.
 Then overload resolution happens
 then accessibility is checked
 
 This happens consistently regardless of virtuality or operatorness
 
 nathan
 
 -- 
 Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
           The voices in my head told me to say this
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
 
 

Re: c++/8821: gcc 3.2 problem with overloaded inherited operator

[reichelt]

Synopsis: gcc 3.2 problem with overloaded inherited operator

State-Changed-From-To: analyzed->closed
State-Changed-By: reichelt
State-Changed-When: Wed Dec 11 01:42:55 2002
State-Changed-Why:
    Not a bug.
    The operator in B hides the one in A.
    See 13.2 in the ISO-standard.

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

Re: c++/8821: gcc 3.2 problem with overloaded inherited operator

[bangerth]

Synopsis: gcc 3.2 problem with overloaded inherited operator

State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Tue Dec 10 14:28:05 2002
State-Changed-Why:
    I can confirm that this problem exists. However, I am
    not sure whether it is really a bug: the operator
    you want to call is simply hidden by the operator
    in the derived class. What I don't know is how lookup
    of member operators happen -- if the same rule applies
    as for virtual functions, then the operator in the base
    class is rightfully hidden; if not, then this is a bug.
    
    On the other hand, if virtual function semantics apply,
    then a function similar to -Woverloaded-virtual should
    exist.

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