Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bbn!bbn.com!lpringle
From: lpringle@bbn.com (Lewis G. Pringle)
Newsgroups: comp.lang.c++
Subject: Re: changing return type of virtual
Summary: Subclassing in Parallel
Message-ID: <43468@bbn.COM>
Date: 28 Jul 89 19:01:29 GMT
References: <1974@cadillac.CAD.MCC.COM>
Sender: news@bbn.COM
Reply-To: lpringle@labs-n.bbn.com (Lewis G. Pringle)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 47

In article <1974@cadillac.CAD.MCC.COM> rpj@redcloud.cad.mcc.com (Rich Johns) writes:
>
>I would like to be able to change the return type of the virtual
>Copy(). G++ 1.35.1 rejects this, and I assume cfront would do the
>same.  I have only recently upgraded to g++ 1.35.1, and was previously
>using 1.32 which allowed me to do this. Could someone explain why this
>is not allowed. It seems like the compiler could easily determine
>whether the change in return type were reasonable or dangerous. That
>is to say, if the changed return type is derived from the return type
>in the base class, let it be.

I agree that this is a misfeature of the C++ language, and there are
related problems which have hounded me.  For much the same reason, I
often want to tell the compiler that a data member (reference or pointer),
is a (reference or pointer) to a subclass of the declared type.

The problem, it that for data members it is ALMOST ALWAYS DANGEROUS, and that
is why (assumtion) the compiler does not allow it.  You see, a base class
pointer could then be used to assign a bad value.

For virtual functions arguments the same danger applies.

However, the specific thing you suggested - return values - does appear
to be safe, and so I too think it should be added to the language.
Any base class calling your method cannot be bothered that the retuned type
was really known to be a (pointer/reference) to a subtype of the type it
expected.  What the feature adds to the language is a type-safe way to help
deal with a very common occurence: parallel subclassing in two hierarchies,
one used by the other.  All in all, I think its a good idea!

BTW, I would be very interested in other peoples ideas about how to deal
with this problem of having an owning class and an owned class, and
subclassing both, and simply getting the right behavior.

Example:
	ScrollBar has an data mamber Thumb.  Now I want to make a
ScrollBarWithSizeableThumb.  I subclass both classes to the right thing,
and add a SetSize() method to thunb (so the ScrollBarWithSIzeableThumb can
reset it).  Now the ScrollBar has an fThumb field of type (Thumb*).  Do
I use this and always cast?  Do I use a new data member fThumb with the new
type and shadow the parent class name?  What is the best way to deal with
this kind of problem????
"OS/2: half an operating system for half a computer."

In Real Life:		Lewis Gordon Pringle Jr.
Electronic Mail:	lpringle@labs-n.bbn.com
Phone:			(617) 873-4433