Newsgroups: comp.lang.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: Overloaded Function Ambiguity Resolution Problems
Message-ID: <1991Mar2.234919.14837@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <1991Feb27.084909.5063@newcastle.ac.uk> <1991Feb27.204841.14690@world.std.com>
Date: Sat, 2 Mar 1991 23:49:19 GMT

In article <1991Feb27.204841.14690@world.std.com> wmm@world.std.com (William M Miller) writes:
>The cfront output is correct, G++ is wrong.  See E&S section 13.1, page 310:
>"Two function declarations of the same name refer to the same function if
>they are in the same scope and have identical argument types (section 13).
>A function member of a derived class is NOT in the same scope as a function
>member of the same name in a base class."  In this example, d->func("hello")
>can only refer to Derived::func(const Base&), since Base::func(char*) is
>hidden in the scope of Derived.

This seems reasonable and powerful, but it isn't what people were saying 
before when we were arguing about the interaction of virtuals/overloads/
conversion.  That gave me the idea g++ was doing it right, although
I disagree with what it's doing!  

So can we take this to mean that only overloading a function (i.e. providing
a definition func(char*)) in the derived class itself should cause this 
behavior ?

Taken as a whole, this statement in E&S would seem to imply that resolution
of which function to call should happen classwise FIRST, exhausting all
possibilities for a subclass-specific function before moving to the base
class.  I would still quibble about the definition of "identical" argument
types in a language that supports builtin conversions, and argue that most
type-and-conversion-safe extensions to an argument list ought to be accepted
as new signatures for the old function.  Of course no sane programmer would
implement it any differently anyway (i.e. Derived::func(char*) HAD BETTER
CALL Derived::func(Base(char*)) ) but it is still a source of potential error
and uncertainty.

-- 
  Craig Hubley   "...get rid of a man as soon as he thinks himself an expert."
  Craig Hubley & Associates------------------------------------Henry Ford Sr.
  craig@gpu.utcs.Utoronto.CA   UUNET!utai!utgpu!craig   craig@utorgpu.BITNET
  craig@gpu.utcs.toronto.EDU   {allegra,bnr-vpa,decvax}!utcsri!utgpu!craig