\section{Inheritance and Templates in Charm++}
\label{inheritance and templates}

\charmpp\ supports inheritance among \charmpp\ objects such as
chares, groups, and messages. This, along with facilities for generic
programming using \CC\ style templates for \charmpp\ objects, is a
major enhancement over the previous versions of \charmpp.

\subsection{Chare Inheritance}
\index{inheritance}

Chare inheritance makes it possible to remotely invoke methods of a base
chare \index{base chare} from a proxy of a derived
chare.\index{derived chare} Suppose a base chare is of type 
\uw{BaseChare}, then the derived chare of type \uw{DerivedChare} needs to be
declared in the \charmpp\ interface file to be explicitly derived from
\uw{BaseChare}. Thus, the constructs in the \texttt{.ci} file should look like:

\begin{alltt}
  chare BaseChare \{
    BaseChare(someMessage *);
    baseMethod(void);
    ...
  \}
  chare DerivedChare : BaseChare \{
    DerivedChare(otherMessage *);
    derivedMethod(void);
    ...
  \}
\end{alltt}

Note that the access specifier \kw{public} is omitted, because \charmpp\
interface translator only needs to know about the public inheritance,
and thus \kw{public} is implicit. A Chare can inherit privately from other
classes too, but the \charmpp\ interface translator does not need to know
about it, because it generates support classes ({\em proxies}) to remotely
invoke only \kw{public} methods.

The class definitions of both these chares should look like:

\begin{alltt}
  class BaseChare : public Chare \{
    // private or protected data
    public:
      BaseChare(someMessage *);
      baseMethod(void);
  \};
  class DerivedChare : public BaseChare \{
    // private or protected data
    public:
      DerivedChare(otherMessage *);
      derivedMethod(void);
  \};
\end{alltt}

Now, it is possible to create a derived chare, and invoke methods of base
chare from it, or to assign a derived chare proxy to a base chare proxy
as shown below:

\begin{alltt}
  ...
  otherMessage *msg = new otherMessage();
  CProxy_DerivedChare *pd = new CProxy_DerivedChare(msg);
  pd->baseMethod();     // OK
  pd->derivedMethod();  // OK
  ...
  Cproxy_BaseChare *pb = pd;
  pb->baseMethod();    // OK
  pb->derivedMethod(); // ERROR
\end{alltt}

Note that \CC\ calls the default constructor \index{default constructor} of the
base class from any constructor for the derived class where base class
constructor is not called explicitly. Therefore, one should always provide a
default constructor for the base class to avoid explicitly calling another base
class constructor.

Multiple inheritance \index{multiple inheritance} is also allowed for Chares
and Groups. However, one should make sure that each of the base classes inherit
``virtually'' from \kw{Chare} or \kw{Group}, so that a single copy of
\kw{Chare} or \kw{Group} exists for each multiply derived class.

One may have {\em virtual} entry methods \index{virtual} in base chare classes.
They are specified by the entry attribute \kw{virtual} in the interface file.
Also, such a method could be pure virtual \index{pure virtual} (where
implementation of this method is not given.) It is noted with the usual \CC\
syntax of ``{\tt =0}'' even in the interface file. Base classes with pure
virtual methods are called {\em abstract} base classes \index{abstract base
class} in OO-lingo. Note that, though instances of abstract base chares cannot
be created, a proxy objects of such a type can be created by constructing it
with the chareID of the concrete derived chare. Invoking methods on this proxy
object would invoke those methods remotely on the concrete derived class
instance.

\subsection{Inheritance for Messages}
\index{message inheritance}

Similar to Chares, messages can also be derived from base messages. One needs
to specify this in the \charmpp\ interface file similar to the Chare
inheritance specification (that is, without the \kw{public} access specifier.)
Message inheritance makes it possible to send a message of derived type to the
method expecting a base class message.

\subsection{Generic Programming Using Templates}
\index{templates}

One can write ``templated'' code for Chares, Groups, Messages and other
\charmpp\  entities using familiar \CC\ template syntax (almost). The \charmpp\
interface translator now recognizes most of the \CC\ templates syntax,
including a variety of formal parameters, default parameters, etc. However, not
all \CC\ compilers currently recognize templates in ANSI drafts, therefore the
code generated by \charmpp\ for templates may not be acceptable to some current
\CC\ compilers\footnote{ Most modern \CC\ compilers belong to one of the two
camps. One that supports Borland style template instantiation, and the other
that supports AT\&T Cfront style template instantiation. In the first, code is
generated for the source file where the instantiation is seen.  GNU \CC\ falls
in this category.  In the second, which template is to be instantiated, and
where the templated code is seen is noted in a separate area (typically a local
directory), and then just before linking all the template instantiations are
generated. Solaris CC 5.0 belongs to this category. For templates to work for
compilers in the first category such as for GNU \CC\ all the templated code
needs to be visible to the compiler at the point of instantiation, that is,
while compiling the source file containing the template instantiation. For a
variety of reasons, \charmpp\ interface translator cannot generate all the
templated code in the declarations file {\tt *.decl.h}, which is included in
the source file where templates are instantiated. Thus, for \charmpp\ generated
templates to work for GNU \CC\ even the definitions file {\tt *.def.h} should
be included in the \CC\ source file. However, this file may contain other
definitions apart from templates that will be duplicated if the same file is
included in more than one source files. To alleviate this problem, we have to
do a little trick. Fortunately, this trick works for compilers supporting both
Borland-style and Cfront-style template instantiation, therefore, code using
this trick will be portable. The trick is to include {\tt *.def.h} with a
preprocessor symbol \kw{CK\_TEMPLATES\_ONLY} defined, whenever templates
defined in an \kw{extern} module are instantiated. If your interface file does
not contain template declarations or definitions, you need not bother about
including {\tt *.def.h} for \kw{extern} modules.  For example, if module {\tt
stlib} contains template definitions, that you may want to instantiate in
another module called {\tt pgm}, then {\tt pgm.C} should include {\tt
stlib.def.h} with \kw{CK\_TEMPLATES\_ONLY} defined. Of course, {\tt
stlib.decl.h} needs to be included at the top of {\tt pgm.C}.  }. 

The \charmpp\ interface file should contain the template
definitions as well as the instantiation. For example, if a message
class \uw{TMessage} is templated with a formal type parameter 
\uw{DType}, then every instantiation of \uw{TMessage} should be specified
in the \charmpp\ interface file. An example will illustrate this better:
\index{template}

\begin{alltt}
  template <class DType=int, int N=3> message TMessage;
  message TMessage<>; // same as TMessage<int,3>
  message TMessage<double>; // same as TMessage<double, 3>
  message TMessage<UserType, 1>;
\end{alltt}

Note the use of default template parameters. It is not necessary for
template definitions and template instantiations to be part of the
same module.  Thus, templates could be defined in one module, and
could be instantiated in another module \index{module}, as long as the
module defining a template is imported into the other module using the
\kw{extern module} construct. Thus it is possible to build a standard
\charmpp\ template library. Here we give a flavor of possibilities:

\begin{alltt}
module SCTL \{
  template <class dtype> message  Singleton;
  template <class dtype> group Reducer \{
    entry Reducer(void);
    entry void submit(Singleton<dtype> *);
  \}
  template <class dtype> chare ReductionClient \{
    entry void recvResult(Singleton<dtype> *);
  \}
\};

module User \{
  extern module SCTL;
  message Singleton<int>;
  group Reducer<int>;
  chare RedcutionClient<int>;
  chare UserClient : ReductionClient<int> \{
    entry UserClient(void);
  \}
\};
\end{alltt}

The \uw{Singleton} message is a template for storing one element of any
\uw{dtype}. The \uw{Reducer} is a group template for a spanning-tree reduction,
which is started by submitting data to the local branch. It also contains a
public method to register the \uw{ReductionClient} (or any of its derived
types), which acts as a callback to receive results of a reduction.
