Path: utzoo!utgpu!watmath!att!dptg!rutgers!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!milano!cadillac!redcloud!rpj
From: rpj@redcloud.cad.mcc.com (Rich Johns)
Newsgroups: comp.lang.c++
Subject: changing return type of virtual
Message-ID: <1974@cadillac.CAD.MCC.COM>
Date: 28 Jul 89 15:43:56 GMT
Sender: news@cadillac.CAD.MCC.COM
Lines: 55

Assume a situation like the following:

class Window {
public:
 virtual Window* Copy();
 // other stuff
};


class BorderedWindow : public Window {
public:
  BorderedWindow* Copy();
// other stuff
};


class ScrollableWindow : BorderedWindow {
public:
  ScrollableWindow* Copy();
// other stuff
};

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'm trying to avoid, what seems to me to be, unecessary casting. If
BorderedWindow and ScrollableWindow each have methods their base
classes do not, then I lose the ability to deal with all of them
generically. For example, only BorderedWindows have a borderWidth, and
only scrollable windows have a ScrollUp() method. What I could do is
define ScrollUp() as a virtual on Window with a dummy definition. This
is alright I guess, although not really intuitive because a plain
window does not scroll. I could also put boderWidth variable on
Window, but this seems even less intuitive. Nonetheless, I would do it
if not for the fact that object Window is part of a library, which I
can't alter. (It just so happens that in this case I could modifiy the
library, but I don't want to do this. I want to be able to pick up new
versions of the library and not have to worry about always
retrofitting my own personal hacks).

I could also establish a new base clas called MyWindow, derived from
Window. But would'nt I then have to rename Copy() to MyCopy() in order
to change its return type? The only solution seems to be messy casting.

Am I thinking about this in the right way?

Rich Johns, MCC CAD Program | 3500 W. Balcones Center Dr., Austin, TX 78759
ARPA: johns@mcc.com         | Phone: [512] 338-3714
UUCP: {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!cadillac!johns