Path: utzoo!news-server.csri.toronto.edu!rutgers!usc!rpi!uupsi!sunic!fuug!funic!news.funet.fi!tukki.jyu.fi!sakkinen
From: sakkinen@tukki.jyu.fi (Markku Sakkinen)
Newsgroups: comp.lang.c++
Subject: Re: Overloaded Function Ambiguity Resolution Problems
Message-ID: <1991Mar12.084906.28195@tukki.jyu.fi>
Date: 12 Mar 91 08:49:06 GMT
References: <1991Feb27.204841.14690@world.std.com> <1991Mar8.105837.15493@tukki.jyu.fi> <1991Mar8.165325.22778@world.std.com>
Reply-To: sakkinen@jytko.jyu.fi (Markku Sakkinen)
Organization: University of Jyvaskyla, Finland
Lines: 47

In article <1991Mar8.165325.22778@world.std.com> wmm@world.std.com (William M Miller) writes:
>sakkinen@tukki.jyu.fi (Markku Sakkinen) writes:
>> ...
>> 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,
>> ...
>> 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.

Apologies for too strong language.  This is certainly an issue on which
sensible persons can have different opinions.

>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.

In the situation you describe, the _interface_ of a class is modified
(by adding a public or protected member function) after other classes
have already been derived from it.  Such a situation should better
(but of course cannot always) be avoided;  not all ensuing problems
are corrected by the name hiding rule.

A very typical situation would be one in which a base class defines
an overloaded function for some argument types and a derived class
would like to add versions for some additional argument types.
The hiding rule makes this impossible.

In my opinion, the difficulties that the hiding rule tries to alleviate
(creating new problems on the way) are to a large part caused
by the too liberal application by C++ of automatic type conversions.
This in turn is a convenience in many situations, of course.

Markku Sakkinen
Department of Computer Science and Information Systems
University of Jyvaskyla (a's with umlauts)
PL 35
SF-40351 Jyvaskyla (umlauts again)
Finland
          SAKKINEN@FINJYU.bitnet (alternative network address)