landon@Apple.COM (Landon Dyer) (12/01/89)
Nano-summary: Pure virtual functions suffer from an apparently arbitrary
language design decision.
Simplified, I have a three-layer class hierarchy, something like this:
TBasicBehaviour -- abstract base, common behaviour for all objects
/
TMumble -- a more specific abstract base
/
TRealMumble -- a class that actually gets instantiated
TBasicBehaviour has a number of pure virtual functions. Derived from this
class are additional abstract bases that add more behaviour, and derived from
THOSE are the classes of which instances are actually made.
In CFront it's necessary to (re-)declare a pure virtual function of a parent
class, even if the subclass itself is abstract. [C++ Reference Manual,
section 10.3, p68 in my copy.]
The problem is that if you have MANY derived abstract bases (and why not?),
this requirement can become painful to maintain. Furthermore, the requirement
appears to be completely arbitrary -- a warning, rather than a hard error
would be sufficient for "mothering" purposes.
So there are a number of possibilities:
o It's impossible to lift the restriction for obscure reasons;
o It's another CFront 2.0 bug;
o This is the way "it turned out";
o It really is a feature;
o I'm completely mistaken and deserve enlightenment ["Oww!"].
I'm willing to listen to arguments about how CFront is doing the right thing,
or about how the current behaviour is merely part of CFront's implementation,
and will be fixed someday.
It WOULD be nice to see a rationale ...
----------------
Here's an example, which you can skip if you like. (You'll have to flatten
this 2-D code to compile it...)
struct A {
virtual f() = 0;
};
struct B1 : A { | struct B2 : A { // etc ==>
virtual f() = 0; | virtual f() = 0;
virtual g() = 0; | virtual h() = 0;
}; | };
struct C1 : B1 { | struct C2 : B2 { // etc ==>
virtual f(); | virtual f();
virtual g(); | virtual h();
}; | };
IMHO, The redeclarations B1::f() and B2::f() should not be required.
Peace,
--
----------------------------------------- "Mmmph! Urghurmph! Grugmph!"
Landon Dyer, Apple Computer, Inc. "What's he trying to say?"
Development Systems Group (MPW / DSG) "I dunno -- there's a lawyer
NOT THE VIEWS OF APPLE COMPUTER crammed in his mouth."MARKV@kuhub.cc.ukans.edu (MARK GOODERUM - UNIV. OF KANSAS ACS - MARKV@UKANVAX) (12/14/89)
In article <36904@apple.Apple.COM>, landon@Apple.COM (Landon Dyer) writes: > Nano-summary: Pure virtual functions suffer from an apparently arbitrary > language design decision. > > > Simplified, I have a three-layer class hierarchy, something like this: > > > TBasicBehaviour -- abstract base, common behaviour for all objects > / > TMumble -- a more specific abstract base > / > TRealMumble -- a class that actually gets instantiated > > > TBasicBehaviour has a number of pure virtual functions. Derived from this > class are additional abstract bases that add more behaviour, and derived from > THOSE are the classes of which instances are actually made. > > In CFront it's necessary to (re-)declare a pure virtual function of a parent > class, even if the subclass itself is abstract. [C++ Reference Manual, > section 10.3, p68 in my copy.] > > I'm willing to listen to arguments about how CFront is doing the right thing, > or about how the current behaviour is merely part of CFront's implementation, > and will be fixed someday. > > It WOULD be nice to see a rationale ... Here is one rationale off the top of my head... Virtual functions exist so that you can declare a general programmer interface and overall structure early in the heirarchy so that your ct your code and the concepts niform as possible. Now suppose you have a class 'vehicle' in which you delclare every conceivalbe action and object associated with a vehicle. For instance you have some virtual functions like drive(), fly(), park(), etc. You then declare derived classes like 'plane' and 'car', which you might further derive into things like 'chevy', 'beechcraft', etc. Now, you DONT want 'chevy' to be able to fly(), although 'beechcraft' can probibly still drive() and park(), although it might not be able to go_drivethru() :-). But you get the idea. By forcing things this way you can design a very general parent class, and only pass on the charecteristics applicable to its children. > Peace, ...on earth, good will towards men.... Merry Christmas, > ----------------------------------------- "Mmmph! Urghurmph! Grugmph!" > Landon Dyer, Apple Computer, Inc. "What's he trying to say?" > Development Systems Group (MPW / DSG) "I dunno -- there's a lawyer > NOT THE VIEWS OF APPLE COMPUTER crammed in his mouth." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Academic Computing Services MARKV@UKANVAX.BITNET University of Kansas "Shopping, done? Ha ha ha ha ha ha ha ha ha ha ha..." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~