<table summary="Identifying information for this document.">
  <tr>
    <th align=right>Doc. No.:</th>
    <td>N2965=09-0155</td>
  </tr>
  <tr>
    <th align=right>Date:</th>
    <td>2009-09-25</td>
  </tr>
  <tr>
    <th align=right>Author:</th>
    <td>Michael Spertus</td>
  </tr>
  <tr>
    <th align=right>Email:</th>
    <td><a href="mailto:mike_spertus@symantec.com">mike_spertus@symantec.com</a></td>
  </tr>
</table>

<h1>Type traits and base classes</h1>
<p>
This paper describes a very simple and powerful type trait that enumerates the
base classes of a class
<p>
The rationale for this can be summed up quickly.
<ul>
<li> According to section 20.6 of the standard, "type property inspection
traits allow important characteristics of types or of combinations of
types to types to be inspected." Certainly, a type's list of base classes
 is one of the most "important characteristics types [and] of combinations of types."
<li> It is extremely useful and powerful as described in the <a href="#motivating_examples">Motivating
  examples</a>   below and (in the author's opinion) could dramatically improve the prominence
  of type traits, one of the most unique, powerful, and forward-looking features of C++0x.
<li> While the existing (and useful) <tt>is_base_of</tt> type trait
  provides a narrow part of this information, it misses critical use
  cases as in the Motivating examples. 
<li>It has wording.</li>
<li>It has been (almost trivially) implemented.</li>
<li>It requires language support, so missing this
  standard cycle means it cannot be made available until the next standard.</li>
</ul>
<h2>The <tt>bases</tt> trait</h2>

This section informally describes the <tt>std::bases</tt> type trait
that gives the base classes of a class. Precise definitions are given
in the Wording section.
<p>
<tt>bases&lt;C&gt;::type</tt> is the
  type <tt>tuple&lt;</tt><em>all base
  classes of <tt>C</tt></em><tt>&gt;</tt>.<br>
<tt>direct_bases&lt;C&gt;::type</tt> is the
  type <tt>tuple&lt;</tt><em>all direct base
  classes of <tt>C</tt></em><tt>&gt;</tt>.
<p>
<b>Notes:</b>
<ul>
<li>Base classes are listed in the order in which they are initialized
  (12.6.2p10).
<li>One would also like to know the nature of the derived-base
  relationship (i.e., is it a virtual base class? Is it a protected
  base class? etc.). A more sophisticated mechanism is
  described in the Section <a href="future_directions">Future
  enhancements</a> below. However, that is a much larger project to
  consider at this stage of the game. We will see that even the very simple traits
  described above enables some of the most important use cases
  (See <a href="#motivating_examples">Motivating examples</a>) without
  in any way precluding tackling the future enhancements at the
  appropriate time.
</ul>
<a name="simple_example"><h2>Simple example</h2></a>
This simple examples illustrates the results of these type traits. In the
Suppose we have the following class hierarchy:

<pre>
class E {};
class D {};
class C : virtual public D, private E {};
class B : virtual public D, public E {};
class A : public B, public C {};
</pre>

It follows that <tt>bases&lt;A&gt;::type</tt> is
<tt>
tuple&lt;D, B, E, C, E&gt;
</tt>
<p>
Similarly, <tt>direct_bases&lt;A&gt;::type</tt> is
<tt>
tuple&lt;B, C&gt;
</tt>

<a name="motivating_examples"><h2>Motivating examples</h2></a>
Writing (roughly) parallel type hierarchies is central to many
programming best practices.
<ul>
  <li>More generally, in the common best practice to separate implementation from
  interface, one creates a type hierarchy of interface classes, and
  then creates a parallel hierarchy if implementation classes that
  inherit from the corresponding interface and from the other
  implementation classes in parallel to the inheritance relationships
  among the interfaces.
<li>When there are multiple ways to implement an interface hierarchy,
  several parallel implementation hierarchies may be created.
  For example, in a hierarchy of widget interfaces where <tt>Pushbutton</tt>
  inherits from <tt>Button</tt>, we would like to
  have implementations <tt>Qt&lt;PushButton&gt;</tt> inheriting
  from <tt>Qt&lt;Button&gt;</tt>, etc., but also  <tt>GTK&lt;PushButton&gt;</tt> inheriting
  from <tt>GTK&lt;Button&gt;</tt>, etc.

<li>By the some token, it is common to separate implementation from
  presentation, so that my datatypes can be presented as text, html,
  Windows, etc. The idea is that the datatype should not have
  a <tt>presentAsHtml()</tt> and supporting methods right in the main
  datatype. Instead, something
  like <tt>HTMLPresentation&lt;MyDataType&gt;</tt>
  prevents <tt>MyDataType</tt> from getting cluttered up with a lot
  HTML-specific logic and the like. Of course
  if <tt>EllipticCurve</tt> inherits from <tt>AlgebraicVariety</tt>,
  then <tt>HTMLPresentation&lt;EllipticCurve&gt;</tt> should inherit
  from  <tt>HTMLPresentation&lt;AlgebraicVariety&gt;</tt> as well, so
  I don't need to reimplement any HTML presentation logic that applies
  to all algebraic varieties.
</ul>
The problem with parallel hierarchies is that they require a lot of
tedious boilerplate to write and keeping these hierarchies in sync as
the interface hierarchies evolve is generally an ongoing maintenance
  nightmare.
<p>
  Indeed, code generation tools like Java's EMF (Eclipse Modeling
  Framework) automatically generate classes in three parallel class hierarchies
  for each UML class; An interface class; an implementation class; and
  a presentation class (referred to as the provider class). Any time a
  change is made to the inheritance hierarchy, all the code needs to
  be regenerated, creating all kinds of merge problems with any
  modifications to the previously generated code skeleton (I am
  experiencing this repeatedly in an EMF project I am involved with).
<p>
In the code below, we suppose that we have a hierarchy
of interface classes that only contain abstract methods and inherit
virtually (i.e., like Java and C# interfaces). 

<p>The following code can
go in an <tt>impl.h</tt> header that automatically generates
implementation classes from an interface and its superclasses.
<table border="2">
<tr><th><tt>impl.h</tt>
<tr><td>
<pre>
template&lt;class T&gt; class impl_base;
template&lt;class T&gt; class impl_helper : virtual public T, public impl_base&lt;typename direct_bases&lt;T&gt;::type&gt; {};
template&lt;class T&gt; class impl : public impl_helper&lt;T&gt; {};
template&lt;&gt; class impl_base&lt;tuple&lt;&gt;&gt; {};

template&lt;class T, typename... remainder&gt;
class impl_base&lt;T, remainder...&gt;&gt; 
  : virtual public impl&lt;T&gt;, public impl_base&lt;tuple&lt;remainder...&gt;&gt; {  
};</pre></td></tr></table>

Now, with no additional code
whatsoever (beyond
<tt>#include "impl.h"</tt>), <tt>impl&lt;PushButton&gt;</tt> automatically
is defined and inherits
from <tt>impl&lt;Button&gt;</tt> (as long as <tt>PushButton</tt>
inherits from <tt>Button</tt>). 

If <tt>impl&lt;PushButton&gt;</tt> can inherit all of its
functionality from  <tt>impl&lt;Button&gt;</tt>, we are done. If not,
adding custom functionality to the implementation classes is almost as
easy:
<pre>
#include "impl.h"
template&lt;&gt;
impl&lt;PushPutton&gt; : public impl_helper&lt;PushButton&gt;
{
  void buttonPushed() { ... } // Implement PushButton::buttonPushed
};
</pre>
and your own class is automatically placed where it belongs in the inheritance
hierarchy.
<p>
Note that programmers that
use <tt>impl.h</tt> don't need to understand type traits or its
internals, any more than users of STL need to understand the STL
sources.
<p>
We can build on this example to create an <tt>impl_family.h</tt>
header that can automatically generate implementation families
parallel to a given interface hierarchy, such as
<tt>Qt&lt;PushButton&gt;</tt>
and <tt>Gtk&lt;PushButton&gt;</tt>, etc.
<table border="2">
<tr><th><tt>impl_family.h</tt>
<tr><td>
<pre>
template&lt;template &lt;typename&gt; class Family, class T&gt; class impl_family_base;
template&lt;template &lt;typename&gt; class Family, class T&gt;
class impl_family_helper : virtual public T, public impl_family_base&lt;Family, typename direct_bases&lt;T&gt;::type&gt;{};

template&lt;template &lt;typename&gt; class Family, class T&gt; class impl_family : public impl_family_helper&lt;Family, T&gt; {};
template&lt;template&lt;typename&gt; class Family&gt; class impl_family_base&lt;Family, tuple&lt;&gt;&gt; {};

template&lt;template&lt;typename&gt; class Family, class T, typename... remainder&gt;
class impl_family_base&lt;Family, tuple&lt;T, remainder...&gt;&gt; 
  : virtual public Family&lt;T&gt;, public impl_family_base&lt;Family,tuple&lt;remainder...&gt;&gt; {};</pre></td></tr></table>
<b>Note:</b> <tt>impl.h</tt> and <tt>impl_family.h</tt> have been confirmed to run well on g++
  4.3.3 (assuming the presence of the <tt>direct_bases</tt> template).
<p>We have programs used at my company where this would automatically
  eliminate thousands of lines of intricate and difficult to maintain
  boilerplate template code.
<p>
It is our hope that examples such as these will convince the reader that inquiring about base classes are sufficiently fundamental to "type
traits" that there will be many good uses (even beyond building parallel hierarchies).


<h2>Wording</h2>

<p>
In Section 20.6.2 (Header <tt>&lt;type_traits&gt;</tt>
synopsis), insert where indicated between
the <span style="color:gray">gray</span> context lines,
<pre>
<span style="color:gray">    template &lt;class... T&gt; struct common_type;</span>
    template&lt;class T&gt;struct bases;  
    template&lt;class T&gt;struct direct_bases;  
<span style="color:gray">  } // <em>namespace std</em></span>
</pre>

Add the following two
rows to the end the table in 20.6.7 (Other transformations), :
<table border="2">
<tr>
<td width="30%"><tt>template &lt;class T&gt; struct bases</tt><td>
<td width="25%"></td>
<td width="45%">If <tt>T</tt> is a class, the member typedef <tt>type</tt> shall
  be a tuple whose types are all base classes of <tt>T</tt> in the
  order specified for initializing bases in 20.6.2. If <tt>T</tt> is
  not a class, then the member typedef <tt>type</tt> shall be a tuple
  with zero arguments</td>
</tr>
<tr>
<td width="30%"><tt>template &lt;class T&gt; struct direct_bases</tt><td>
<td width="25%"></td>
<td width="45%">If <tt>T</tt> is a class, the member typedef <tt>type</tt> shall
  be a tuple whose types are all direct base classes of <tt>T</tt> in the
  order specified for initializing bases in 20.6.2. If <tt>T</tt> is
  not a class, then the member typedef <tt>type</tt> shall be a tuple
  with zero arguments</td>
</tr></table>
<p>
Add the following to the end of 20.6.7:
<p>
[<em>Example</em><br>
<pre>
class E {};
class D {};
class C : virtual public D, private E {};
class B : virtual public D, public E {};
class A : public B, public C {};
</pre>
<tt>  // </tt><em> the following assertions hold:</em><br>
<pre>
assert((is_same&lt;bases&lt;A&gt;::type, tuple&lt;D, B, E, C, E&gt;&gt;::value));
assert((is_same&lt;direct_bases&lt;A&gt;::type, tuple&lt;B, C&gt;&gt;::value));
</pre>
&mdash; <em>end example</em><tt>]</tt>
<a name="future_directions"><h2>Appendix: Future enhancements</h2></a>
Obviously, the traits described above offer a very simplified view of
the type system (e.g., not recognizing virtual inheritance or
accessibility constraints). Eventually, we would like a more
full-featured system for metaprogramming the type system. As it is
always good to have a vision, this section
describes one possible thought as to how this may evolve and what a
future system for modeling base class relationships (maybe even
broader reflection) could look like.
<p>
The important thing to note is that there is no harm and much
advantage in implementing
the traits above at the earliest opportunity, even if we add a more full-featured framework
later. The main point is that the <tt>bases</tt>
and <tt>direct_bases</tt> are fully consistent with the approach
currently taken by  <tt>is_base_of</tt> to model base class relations. If we have <tt>is_base_of</tt>,
we might as well have <tt>bases</tt>, as it gives us much more power
without being committal about the future. Indeed, the sketch below
also includes a <tt>base_occurrences</tt> type trait that adds all the
same detail to <tt>is_base_of</tt>. In the author's opinion, there is no
reason to hold back on adding <tt>bases</tt> and <tt>direct_bases</tt>
at soon as possible because of fear that something
better (perhaps different than described below) could be implemented down the road.

<h3>The <tt>describe_bases</tt> trait</h3>

This section informally describes the <tt>std::describe_bases</tt> type trait
that gives a detailed description of the base classes of a class.
<p>
Since C++ supports many types of base classes, as a preliminary to
describing the <tt>bases</tt> type trait, we define
a <tt>base_info</tt> class whose template parameters describe the
relationship of a class to its parent to allow accurate reconstruction
of the inheritance hierarchy.

<pre>
namespace std {
  enum member_accessibility {
    public_accessibility,
    protected_accessibility,
    private_accessibility,
    inaccessible
  };

  template&lt;class baseT, bool direct, bool virt, member_accessibility access&gt; 
  class base_info {
  public:
    typedef baseT base;  
    const static bool is_direct = direct;
    const static bool is_virtual = virt;
    const static member_accessibility accessibility = access;
  };
}
</pre>

Now we are ready to describe the <tt>describe_bases</tt> type trait.
<p>
<tt>describe_bases&lt;C&gt;::type</tt> is the
  type <tt>tuple&lt;</tt><em><tt>base_info</tt> for all base
  classes of <tt>C</tt></em><tt>&gt;</tt>.
<p>Base classes are listed in the order in which they are initialized
  (12.6.2p10).

<h3>Helper traits</h3>
While the <tt>bases</tt> trait gives us what we absolutely need for
walking the type hierarchy, the following "helper" type traits are "very nice
to have," avoiding compile-time and space-intensive
metaprograms for common scenarios.
<p/>
Since the inheritance hierarchy is generally understood as a tree, an
easy way to enumerate the direct base classes of a class is generally what we
need to walk a class' inheritance hierarchy:
<p>
<tt>describe_direct_bases&lt;C&gt;::type</tt> is
  the type <tt>tuple&lt;</tt><em><tt>base_info</tt> for all direct base
  classes of <tt>C</tt></em><tt>&gt;</tt>.
<p/>
The existing
<tt>is_base_of</tt> type trait says that a class is a base class of
another, but does not say anything about what kind of base class. We
can extend the <tt>is_base_of&lt;B, D&gt;</tt> with the following type
trait:
<p/>
<tt>base_occurrences&lt;B, D&gt;</tt>
  is <tt>tuple&lt;</tt><em><tt>base_info</tt> for all occurrences
  of <tt>B</tt> as a base class of <tt>D</tt></em><tt>&gt;</tt>.
<p>
<h3>Simple example</h3></a>
This simple examples illustrates the results of these type traits. In the
Suppose we have the following class hierarchy:

<pre>
class E {};
class D {};
class C : virtual public D, private E {};
class B : virtual public D, public E {};
class A : public B, public C {};
</pre>

It follows that <tt>describe_bases&lt;A&gt;::type</tt> is
<pre>
tuple&lt;base_info&lt;D, false, true, public_accessibility&gt;,
      base_info&lt;B, true, false, public_accessibility&gt;,
      base_info&lt;E, false, false, public_accessibility&gt;,
      base_info&lt;C, true, false, public_accessibility&gt;,
      base_info&lt;E, false, false, inaccessible&gt;&gt; // Not accessible in A
</pre>
<p>
<br>
and that <tt>describe_direct_bases&lt;A&gt;::type</tt> is
<pre>
tuple&lt;base_info&lt;B, true, false, public_accessibility&gt;,
      base_info&lt;C, true, false, public_accessibility&gt;&gt;
</pre>
<p><br>
We also have that <tt>base_occurrences&lt;E, A&gt;::type</tt> is
<pre>
tuple&lt;base_info&lt;E, false, false, public_accessibility&gt;,
      base_info&lt;E, false, false, inaccessible&gt;&gt;
</pre><p><br>

Of course,  <tt>base_occurrences&lt;B, C&gt;::type</tt> is just <tt>tuple&lt;&gt;</tt>.

<h3>Extended example</h3>


<p>The following code shows how to produce a file equivalent to
the <tt>impl.h</tt> header described in
  the <a href="motivating_examples">Motivating examples</a> above.


<pre>
template&lt;class T&gt; class impl_base;
template&lt;class T&gt; class impl_helper : virtual public T, public impl_base&lt;typename describe_direct_bases&lt;T&gt;::type&gt; {};
template&lt;class T&gt; class impl : public impl_helper&lt;T&gt; {};
template&lt;&gt;class impl_base&lt;tuple&lt;&gt;&gt; {};

template&lt;class T, typename... remainder&gt;
class impl_base&lt;tuple&lt;base_info&lt;T, true, true, public_accessibility &gt;,remainder...&gt;&gt; 
  : virtual public impl&lt;T&gt;, public impl_base&lt;tuple&lt;remainder...&gt;&gt; {  
};
</pre>

This acts like the previous <tt>impl.h</tt>. However, it produces a
compiler diagnostic if the assumption of virtual inheritance is among
the interfaces is violated. It also can be fine tuned to handle
different base class accessibilities as appropriate, unlike the
previous one, which inappropriately propagates private base classes to
the implementation hierarchy.
<p>
<b>Note:</b>This <tt>impl.h</tt> has also been confirmed to run perfectly on g++
  4.3.3 (assuming the presence of the <tt>describe_direct_bases</tt> template).

