joshua@paul.rutgers.edu (Josh Mittleman) (05/09/91)
We can simplify the picture a little:
class Object {
public:
virtual void Draw() = 0;
virtual void Update() = 0;
virtual Object* Dup() = 0;
};
class Line: public virtual Object {
public:
void Draw();
};
class Dependent: public virtual Object {
public:
void Update();
};
class DependentLine: public Line, public Dependent {
public:
Object *Dup() { return new DependentLine; }; // error here
};
I'm pretty sure that the problem is that you have an ambiguity. For
DependentLine not to be an abstract class, it needs to have an unambiguous
definition for each pure virtual function. Dup() is defined locally, but
the Update() and Draw() need to be inherited. But, there are two routes
through which to inherit them: from Line, in which Update() is still pure
virtual, and from Dependent, in which Draw() is still pure virtual.
I can't find anything in ARM which covers this problem specifically, but
obviously what's happening is that one or both of these is being inherited
as pure virtual, and so DependentLine is considered abstract. I guess this
is consistent with the way that C++ deal with other ambiguities: Don't flag
an error until the ambiguity is actually invoked.
===========================================================================
Josh Mittleman (mittle@watson.ibm.com or joshua@paul.rutgers.edu)
J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598
--
------------------------------------------------------------------------------
Joshua Mittleman (mittle@watson.ibm.com or joshua@paul.rutgers.edu)
J2-C28 T.J. Watson Research Institute, PO Box 704, Yorktown Heights, NY 10598comeau@ditka.Chicago.COM (Greg Comeau) (05/10/91)
In article <May.8.13.41.48.1991.18969@paul.rutgers.edu> joshua@paul.rutgers.edu (Josh Mittleman) writes: >class Object { public: virtual void Draw() = 0; virtual void Update() = 0; > virtual Object* Dup() = 0; }; >class Line: public virtual Object { public: void Draw(); }; >class Dependent: public virtual Object { public: void Update(); }; >class DependentLine: public Line, public Dependent { >public: Object *Dup() { return new DependentLine; }; // error here >}; >I can't find anything in ARM which covers this problem specifically, but >obviously what's happening is that one or both of these is being inherited >as pure virtual, and so DependentLine is considered abstract. Exactly. Check out something like page 214 of the ARM where we should be told that pure virtual are inherited as pure virtuals. What's ended up having then is that Line is abstract since it doesn't redefine Update or Dup. Dependent is abstract since it doesn't redefine Draw or Dup. And since Dependentline is based on Abstract classes containing pure virtuals, it too must be abstract since it doesn't redefine Draw or Update! (Are we having fun yet?). >I guess this is consistent with the way that C++ deal with other ambiguities: >Don't flag an error until the ambiguity is actually invoked. Not at all. Since you can't create an instance of an abstract class, there was nothing wrong until the new was seen. Having a hierarchy of abstract classes is sometimes a desirable thing. It's all fully in accord to C++'s typing/safety philosophy as well. - Greg -- Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of Comeau C++ 2.1 Here:attmail.com!csanta!comeau / BIX:comeau / CIS:72331,3421 Voice:718-945-0009 / Fax:718-441-2310