\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.

\section{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 \{
    entry BaseChare(someMessage *);
    entry void baseMethod(void);
    ...
  \}
  chare DerivedChare : BaseChare \{
    entry DerivedChare(otherMessage *);
    entry void 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 *);
      void baseMethod(void);
  \};
  class DerivedChare : public BaseChare \{
    // private or protected data
    public:
      DerivedChare(otherMessage *);
      void 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(); // COMPILE 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, or explicitly call another base
class constructor.

Multiple inheritance \index{multiple inheritance} is also allowed for Chares
and Groups. Often, one should make 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.

Entry methods are inherited in the
same manner as methods of sequential \CC{} objects.  
To make an entry method virtual, just add the keyword \kw{virtual}
to the corresponding chare method-- no change is needed in the interface file.
Pure virtual entry methods also require no special description
in the interface file.


\section{Inheritance for Messages}

\index{message inheritance}

Messages cannot inherit from other messages.  A message can, however,
inherit from a regular \CC\ class.  For example:

\begin{alltt}
//In the .ci file:
  message BaseMessage1;
  message BaseMessage2;

//In the .h file:
  class Base \{
    // ...
  \};
  class BaseMessage1 : public Base, public CMessage_BaseMessage1 \{
    // ...
  \};
  class BaseMessage2 : public Base, public CMessage_BaseMessage2 \{
    // ...
  \};
\end{alltt}

Messages cannot contain virtual methods
or virtual base classes unless you use a packed message.
Parameter marshalling has complete support for inheritance, virtual
methods, and virtual base classes via the PUP::able framework.


% ( I think the following is now a lie  OSL 7/5/2001 )  
%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.


\section{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

\newcommand{\longcompilerfootnote}{\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 parts of
    the definitions file {\tt *.def.h} should be included in the \CC\
    source file. }}

Since many modern \CC\ compilers\longcompilerfootnote\ require that
the template definitions (in \emph{addition} to the template
declarations) be available in all sources which use them, you will
need to include the templated Charm definitions in your header file.
That is, given a module {\tt stlib}, in addition to having a line {\tt
  \#include "stlib.decl.h"} in your header file (e.g. {\tt stlib.h}),
you also need the following lines towards the end of the file:

\begin{alltt}
#define CK_TEMPLATES_ONLY
#include "stlib.def.h"
#undef CK_TEMPLATES_ONLY
\end{alltt}

This has the effect of including into the header file only those
declarations which relate to templates.  You will \emph{still} need to
include the file {\tt stlib.def.h} \emph{again} in your implementation
sources (i.e., {\tt stlib.C}) in order to pick up the rest of the
(non-template-related) definitions.  Note that for completely
template-based libraries, this means that you might need to create an
implementation file {\tt stlib.C} when you otherwise wouldn't solely
for the purpose of making sure that the non-template definitions in
{\tt stlib.def.h} are included and compiled.

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.
