nobody@tekecs.TEK.COM (-for inetd server command) (02/18/89)
I'm using cfront 1.2, and I wan to build a set of classes derived from an
abstract base class which are a kind of "smart pointer", i.e., they can
retrieve the objects they point to from storage somewhere if they are not
currently resident in the program's address space.
The macro solution to generic container classes is not appealing, and I'm
willing to put up with some limitations to avoid it, but one thing disturbs
me: I can't have virtual functions which are declared to return an object
of the type which the derived class manages, even if it's a subclass of the
type managed by the bas class. For instance:
class Base
{
public:
virtual void* Obj() { return obj; }
protected:
void* obj;
};
class Derived : public Base
{
public:
virtual int Obj() { return (int)obj; }
};
gives me the following message:
error: virtual Derived::Obj() type mismatch: int Derived::() and void *Base::()
even though void* is in effect an anonymous type, and there is not
really a type mismatch. Obviously, I can get this example to compile by
making the functions non-virtual, but that removes the nice polymorphism I
wanted to begin with.
Question 1: is this really a language issue, or just a quirk of the current
version of cfront?
Question 2: can anyone suggest a way around this?
Bruce Cohen
Interactive Technologies Division, Tektronix, Inc.
M/S 61-028, P.O. Box 1000, Wilsonville, OR 97070
brucec@demiurge.gwd.tek.com, SOON TO BE: brucec@orca.wv.tek.com shopiro@alice.UUCP (Jonathan Shopiro) (02/19/89)
In article <11034@tekecs.TEK.COM>, brucec@demiurge.gwd.tek.com (Bruce Cohen) writes: > ... > > struct Base > { > virtual void* Obj() { return obj; } > void* obj; > }; > struct Derived : public Base > { > virtual int Obj() { return (int)obj; } > }; > > gives me the following message: > > error: virtual Derived::Obj() type mismatch: int Derived::() and void *Base::() > > Question 1: is this really a language issue, or just a quirk of the current > version of cfront? This is really a language issue. At the point of call of a virtual function the code doesn't know what function is going to be called. Thus the calling sequence and arrangements for receipt of the return value must be identical for each instance of any virtual function, and the only way to guarantee that is to require that they have the same types. For example, suppose your example were allowed and then you tried to port the program to a machine that returned integers in one register and pointers in another. Disaster would likely occur. > Question 2: can anyone suggest a way around this? Try to avoid using base classes as unions. The macro technique for container classes works, if your cpp is robust. - - - - - - - -- Jonathan Shopiro AT&T Bell Laboratories, Warren, NJ 07060-0908 research!shopiro (201) 580-4229