Newsgroups: comp.std.c++
Path: utzoo!utgpu!craig
From: craig@gpu.utcs.utoronto.ca (Craig Hubley)
Subject: Re: Co-ordinating the polymorphism in C++
Message-ID: <1991Feb21.184532.20291@gpu.utcs.utoronto.ca>
Organization: Craig Hubley & Associates
References: <DSOUZA.91Feb14151948@optima.cad.mcc.com> <1991Feb16.114422.14266@gpu.utcs.utoronto.ca> <27BFE464.3FB9@tct.uucp> <1991Feb19.120934.22963@kodak.kodak.com>
Date: Thu, 21 Feb 1991 18:45:32 GMT

In article <1991Feb19.120934.22963@kodak.kodak.com> cok@islsun.Kodak.COM (David Cok) writes:
>In article <27BFE464.3FB9@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>>According to craig@gpu.utcs.utoronto.ca (Craig Hubley):
>>>I want the compiler to override the base class's function wherever
>>>a derived function is defined that
>>>	- accepts a parameter list convertible to one the base would accept
>>>	- returns a value of a type convertible to one returned by base
>>>my definition of "convertible" is quite restrictive here:  pointers to 
>>>derived classes, which are legal substitutes for pointers to bases.
>
>My original post which started part of this thread asked only for the
>second of Craig's requests (including references as well as pointers) -- that
>
>	... nice description omitted...
>
>Either (but not both at once) returning D* or returning B* would be legal.
>Since returning D* is now illegal, no code would break or have its
>semantics changed.
>
>I realize that this proposal does not address all the concerns
>of other posters (e.g. Craig Hubley) related to conversions on function
>parameters.  However, in my (couple of years) of C++ use being able to do

So far as I know I am the only one on the net at present proposing that these
conversion rules be extended explicitly to function parameters.  The language
already supports an implicit form of this, of course, by allowing conversions
to be invoked when calling a function.  I am arguing for it to be made
explicit.  My concern is that several levels down in the type matrix these
restrictions on optional arguments or on declaring the type of the argument
will become unacceptable, and I (or someone else) will have to create a new
function with a new name.  Thus a set of capabilities that could have been
one polymorphic function becomes two, and the complexity of knowing which
to call ends up on the programmer again.  This restricts reusability too,
since code that deals with the base types can't handle the derived types
lower down the hierarchy since the function name has changed.

>what I propose for return types would have reduced the number of helper
>functions and lines of code significantly (10s of percent), whereas the

I would agree with this assessment.

>restrictions on function argument types have rarely been a problem for me.

Probably because of the already-powerful conversion system.  I am only
proposing that this be explicitly recognized when compiling overloaded or
virtual functions.

>conversions on function arguments caused a significant simplification.

C++ already supports such conversion, and you can see good examples of the 
value of it (e.g. int to float) anywhere.  However, it doesn't let the
programmer declare or enforce any constraints.  If I was not allowed to
write a function to divide even ints and produce an int, then I would
always be invoking the float version at significant additional overhead.
It would also be confusing if int/int produced a float, which is the issue
we are addressing talking about return types.  Being able to tailor
based on the arguments can improve efficiency, but if C++ converts them
with a general conversion function (e.g. a constructor) so that a generalized
function can deal with them, this gain is lost.  It is more a question of
overhead than simplification in this case.


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