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