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 10598
comeau@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