This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/8821: gcc 3.2 problem with overloaded inherited operator
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: Wolfgang Bangerth <bangerth at ticam dot utexas dot edu>
- Cc: andre at kiwisound dot de, gcc-bugs at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
- Date: Wed, 11 Dec 2002 15:15:11 +0000
- Subject: Re: c++/8821: gcc 3.2 problem with overloaded inherited operator
- References: <Pine.LNX.4.44.0212110841280.4615-100000@gandalf.ticam.utexas.edu>
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