TITLE: Using a typedef for superclass


PROBLEM: greg@afs.com

We have a bunch of Objective-C code (on NeXT) that we will be porting to  
C++ (on Windows), and most of the functional mapping is self-evident. The  
thing I can't find in any of our reference books is an equivalent to  
'super', which is the chain of all base classes behind the current derived  
class. We use this to incrementally refine methods.


RESPONSE: dag@control.lth.se (Dag Bruck), Dept of Auto. Control, Lund, Sweden
	  8 Apr 93

The following approach was suggested by Mike Tiemann at a C++
standardization meeting when this issue came up.

The idea is to insert a private "typedef" in every derived class.

	class Base {
	public:
	  virtual void foo();
	  // ....
	};

	class Derived : public Base {
	  typedef Base inherited;
	  // "inherited" is now a private alias for Base.
	public:
	  void foo();
	  // ....
	};

	void Derived::foo()
	{
	  inherited::foo();	// do whatever base class does
	  // additional stuff
	}

If you ever change the class hierarchy or the name of the base class,
you must also change all the local typedef in the immediately derived
classes.  This is a minor pain, but not particularly error-prone
because the typedef is so close to the line which specifies the base
class (which must be changed anyway).

The great advantage (of "super", really) is that you do not sprinkle
class hierarchy dependencies all over your code.  There is a
significant risk that any explicit reference to a base class that you
forget to change goes by undetected, for example, if you insert a new
class in the middle of the class hierarchy, or if you call a static
member function.  Given the original class derivation change

	Base -> Derived

we change it to

	Base -> Base2 -> Derived

Assume that the original code was

	void Derived::foo()
	{
	  Base::foo();	// do whatever base class does
	  // additional stuff
	}

This is still a valid piece of C++ code after changing the derivation
chain, but probably not what the programmer had in mind (if Base2 also
redefines virtual function foo).  The trick with defining a local
typedef for "inherited" gets us around this particular pitfall.

The rare case where the typedef does not help much is when we convert
from single inheritance to multiple inheritance and foo() is defined
in both base classes.  In this case a built-in "super" would be
ambiguous so the problem would be immediately highlighted at the next
compilation.  The typedef always points to one of the base classes, so
the code is still correct from the compiler's point of view.  One can
always hope that the existence of the typedef makes the programmer
consider that there is a potential conflict; simply removing the
typedef will of course pin-point any use of "inherited" (remember to
make the typedef private, otherwise you will simply inherit a typedef
from an intermediate base class), which will make fixing the code
easy.