Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!wmm
From: wmm@world.std.com (William M Miller)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded Function Ambiguity Resolution Problems
Message-ID: <1991Mar8.165325.22778@world.std.com>
Date: 8 Mar 91 16:53:25 GMT
References: <1991Feb27.084909.5063@newcastle.ac.uk> <1991Feb27.204841.14690@world.std.com> <1991Mar8.105837.15493@tukki.jyu.fi>
Organization: The World Public Access UNIX, Brookline, MA
Lines: 42

sakkinen@tukki.jyu.fi (Markku Sakkinen) 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.
> >
> >-- William M. Miller, Glockenspiel, Ltd.
> >   wmm@world.std.com
>
> The functions in the example have _not_ got identical argument types!
> The problem seems to be that a new function declared in a derived
> class hides _all_ functions with the same name in the base class,
> no matter what the number and types of arguments.
> If the constructor 'Base (char*)' were not there,
> the invocation of 'func' would evidently cause a compiler diagnostic.

Sorry if I wasn't explicit enough or if the citation from E&S was confusing.
Yes, that's exactly what I was saying: lookup is by name only, not name and
function signature.  The search stops at the nearest scope with a
declaration of the name, and if it's the wrong type, the compiler reports an
error rather than continuing the search.

> Current C++ has a lot of complicated and stupid visibility rules,
> as if expressly designed to shoot programmers in the back;
> this is one of them.

Actually, it's designed to prevent programmers being shot in the back, as it
were; having to look through all the levels of a deeply-nested hierarchy to
determine which of a set of overloaded member functions will be invoked by a
given call, as would be necessary if hiding were by name and signature
instead of name alone, is tedious and error-prone.  It's especially
dangerous in that the addition of an overloaded member function in a base
class would be able to hijack a call that used to resolve to a derived class
member function.  This kind of bug can be very difficult to track down: all
you know is that your program used to work before you installed the new
version of the library but that it doesn't work now.

-- William M. Miller, Glockenspiel, Ltd.
   wmm@world.std.com