<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  <meta name="generator" content="Docutils 0.3.10: http://docutils.sourceforge.net/"/>
  <title>Base class aliases for The-C++-After-0x</title>
  <meta name="author" content="James Widman &amp; Thorsten Ottosen"/>
  <meta name="date" content="2009-04-28"/>
  <style type="text/css">

/*
Stylesheet info:
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:Date: $Date: 2005-09-25 17:49:54 +0200 (Sun, 25 Sep 2005) $
:Revision: $Revision: 3901 $
:Copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.

See http://docutils.sf.net/docs/howto/html-stylesheets.html for how to
customize this style sheet.
*/

/* "! important" is used here to override other ``margin-top`` and
   ``margin-bottom`` styles that are later in the stylesheet or 
   more specific.  See http://www.w3.org/TR/CSS1#the-cascade */
.first {
  margin-top: 0 ! important }

.last, .with-subtitle {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dl.docutils dd {
  margin-bottom: 0.5em }

/* Uncomment (and remove this text!) to get bold-faced definition list terms
dl.docutils dt {
  font-weight: bold }
*/

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.admonition, div.attention, div.caution, div.danger, div.error,
div.hint, div.important, div.note, div.tip, div.warning {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.admonition p.admonition-title, div.hint p.admonition-title,
div.important p.admonition-title, div.note p.admonition-title,
div.tip p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

/* Uncomment (and remove this text!) to get reduced vertical space in
   compound paragraphs.
div.compound .compound-first, div.compound .compound-middle {
  margin-bottom: 0.5em }

div.compound .compound-last, div.compound .compound-middle {
  margin-top: 0.5em }
*/

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  clear: both;
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1.section-subtitle, h2.section-subtitle, h3.section-subtitle,
h4.section-subtitle, h5.section-subtitle, h6.section-subtitle {
  margin-top: 0.4em }

h1.title {
  text-align: center }

h2.subtitle {
  text-align: center }

hr.docutils {
  width: 75% }

img.align-left {
  clear: left }

img.align-right {
  clear: right }

img.borderless {
  border: 0 }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee }

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

span.section-subtitle {
  /* font-size relative to parent (h1..h6 element) */
  font-size: 80% }

table.citation {
  border-left: solid thin gray }

table.docinfo {
  margin: 2em 4em }

table.docutils {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.footnote {
  border-left: solid thin black }

table.docutils td, table.docutils th,
table.docinfo td, table.docinfo th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

table.docutils th.field-name, table.docinfo th.docinfo-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap ;
  padding-left: 0 }

h1 tt.docutils, h2 tt.docutils, h3 tt.docutils,
h4 tt.docutils, h5 tt.docutils, h6 tt.docutils {
  font-size: 100% }

tt.docutils {
  background-color: #eeeeee }

ul.auto-toc {
  list-style-type: none }

  </style>
</head>

<body>
<div class="document" id="base-class-aliases-for-cpp-0x-plusplus">
<h1 class="title">Base Class Aliases for The-C++-After-0x</h1>
<table class="docinfo" frame="void" rules="none">
  <col class="docinfo-name"/>
  <col class="docinfo-content"/>
  <tbody valign="top">
    <tr>
      <th class="docinfo-name">Author:</th>
      <td>James Widman &amp; Thorsten Ottosen</td>
    </tr>
    <tr>
      <th class="docinfo-name">Contact:</th>
      <td><a class="first reference" >widman -&gt; gimpel dot com</a>
&amp; <a class="last reference" >thorsten dot ottosen -&gt; dezide dot com</a></td>
    </tr>
    <tr class="field">
      <th class="docinfo-name">Organizations:</th>
      <td class="field-body">Gimpel Software &amp; Dezide Aps</td>
    </tr>
    <tr>
      <th class="docinfo-name">Date:</th>
      <td>2009-04-28</td>
    </tr>
    <tr class="field">
      <th class="docinfo-name">Number:</th>
      <td class="field-body">N2881=09-0071<br/>
      </td>
    </tr>
    <tr class="field">
      <th class="docinfo-name">Working Group:</th>
      <td class="field-body">Evolution</td>
    </tr>
  </tbody>
</table>
<div class="abstract topic">
<p class="topic-title first">Abstract</p>
<p>
[NOTE!  We strongly suggest that EWG ignore this proposal until 
<b><em>after</em></b> the FDIS for C++0x ships.]
</p>
<p>This paper provides motivation and a design proposal for base class
aliases.  A <em>base class
alias</em> simplifies the naming of a base class by enabling the use of
the new <em>alias-declaration</em> syntax (see [dcl.typedef]) as part of
the syntax for a <em>base-specifier</em> in order to define a typedef name
for the base class right inside the <em>base-specifier</em>.

</p>
</div>
<!-- ######################### -->
<!-- # Roles --><!-- ######################### -->
<div class="contents topic">
<p class="topic-title first"><a id="table-of-contents"
 name="table-of-contents">Table of Contents</a></p>
<ul class="simple">
  <li><a class="reference" href="#motivation" id="id2" name="id2">Motivation</a></li>
  <li><a class="reference" href="#similar-proposals" id="id3" name="id3">Similar
proposals</a></li>
  <li><a class="reference" href="#implementability" id="id4" name="id4">Implementability</a></li>
  <li><a class="reference" href="#impact" id="id4" name="id4">Impact</a></li>
  <li><a class="reference" href="#design-considerations" id="id5"
 name="id5">Design considerations</a></li>
</ul>
</div>
<!-- section-numbering: -->
<div class="section">
<h1><a class="toc-backref" href="#id2" id="motivation" name="motivation">Motivation</a></h1>
<p>
The motivation is simple:  when the name of a base class is a
<em>template-id</em>, repeating it becomes unpalatable.  For example,
after preprocessing, one popular implementation of std::bitset looks like
this:
</p>
<pre class="literal-block">
  template&lt;size_t _Nb&gt;
    class bitset
    : private _Base_bitset
        &lt;
        ((_Nb) &lt; 1
        ? 0
        : ((_Nb) + numeric_limits&lt;unsigned long&gt;::digits - 1)
            / numeric_limits&lt;unsigned long&gt;::digits)
        &gt;
    {
    private:
      typedef _Base_bitset
            &lt;
            ((_Nb) &lt; 1
            ? 0
            : ((_Nb) + numeric_limits&lt;unsigned long&gt;::digits - 1)
                / numeric_limits&lt;unsigned long&gt;::digits)
            &gt;
      _Base;
    // [...]
    };
</pre>

<p>We propose the introduction of a small pure language extension that
enables the definition of a typedef name for a base class 
<em>at the point of its base-specifier </em>.  The syntax would echo both 
<ul>
    <li>the new style of typedef name definition as in 
'using N = int;' (see [dcl.typedef]) and</li>
    <li>the syntax for a concept instance alias definition (see
    [temp.req]).</li>
</ul>
Naturally, a base class alias name would be visible to name lookup
immediately after its <em>base-specifier</em> (so that it could be used in
subsequent
<em>base-specifier</em>s). 
But there is a slight twist: since it's a very common practice to define
a typedef name for a base class as a member of the derived class, we
propose that each base
alias name be implicitly injected as a member typedef name within the
scope of the derived class (just as if the user had written the typedef
there, and right at the point where the injected-class-name is injected).
<p>Example: With base class aliases, the definition of bitset could be
rewritten to the following (somewhat-less appalling) version:</p>
<pre class="literal-block">
  template&lt;size_t _Nb&gt;
    class bitset
    : _Base = private _Base_bitset
        &lt;
        ((_Nb) &lt; 1
        ? 0
        : ((_Nb) + numeric_limits&lt;unsigned long&gt;::digits - 1)
            / numeric_limits&lt;unsigned long&gt;::digits)
        &gt;
    // '_Base' is now in scope here
    {
    // The name '_Base' is also  injected here
    // as a private typedef name (along
    // with the injected-class-name).

    // [...]
    };
</pre>
<p>Here is another example from a fairly simple Boost library</p>
<pre class="literal-block">template
&lt;
    class T,
    class CloneAllocator,
    class Allocator     
&gt;
class ptr_vector :
    public ptr_sequence_adapter&lt; T,
                                std::vector&lt;void*,Allocator&gt;,
                                CloneAllocator &gt;
{
    typedef ptr_sequence_adapter&lt; T,
                                  std::vector&lt;void*,Allocator&gt;,
                                  CloneAllocator &gt;
        base_class; 
</pre>
<p>Again, the length of the template-id naming the base class is an enemy
of readability and maintainability. With base class aliases we could 
rewrite the
example as:</p>
<pre class="literal-block">template
&lt;
    class T,
    class CloneAllocator,
    class Allocator
&gt;
class ptr_vector : <em>base_class =</em> 
    public ptr_sequence_adapter&lt; T,
                                std::vector&lt;void*,Allocator&gt;,
                                CloneAllocator &gt;
{
</pre>
<!-- // an additional alias name 'base_class' -->
<!-- // is also placed in the scope of ptr_vector here.  -->

<p>
The benefits are compounded when one base-specifier depends on another. Example:
</p>
<pre class="literal-block">template&lt; class T, class U, class V &gt;
class Foo : <em>base1 =</em> public some_base&lt;T,U,V&gt;, 
            <em>base2 =</em> public another_base&lt;<em>base1</em>,T,U,V&gt;,
            // ...
{
</pre>

<p>We can summarise the advantages of this feature as follows:</p>
<ol class="arabic simple">
  <li>it makes it easier to write code involving base classes</li>
  <li>it makes it easier to maintain code involving base classes</li>
  <li>it generalizes the use of the <tt class="docutils literal"><span
 class="pre">super</span></tt> keyword often seen in
languages with single inheritance</li>
  <li>it makes the language more accessible to novices and experts alike</li>
</ol>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id4" id="implementability"
 name="implementability">Implementability</a></h1>
<p>We believe the proposal is straightforward to implement.</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id4" id="impact"
 name="impact">Impact</a></h1>
<p>We are not yet aware of any <em>novel</em> adverse effects that would
be invited by this proposal.  Indeed, there should be few or none because
it merely appends to the list of syntactic contexts where a typedef name
can be introduced into some scope.
</p>
</div>
<div class="section">
<h1><a class="toc-backref" href="#id5" id="design-considerations"
 name="design-considerations">Design considerations</a></h1>
<p>The access of the injectecd base alias name is an open issue.
Consider the following example</p>
<pre class="literal-block">
class Foo : <em>base1 =</em> public    some_base,
            <em>base2 =</em> protected another_base,
            <em>base3 =</em> private   yet_another_base
{}; 

typedef Foo::base1 base1; // OK?
typedef Foo::base3 base3; // ERROR, 'base3' is a private name

class Bar : public Foo
{
    typedef base2 foos_2nd_base; // OK?
};
</pre>
<p>We suspect that the syntax should enable the user to explicitly
indicate the access of the injected typedef name:
<pre class="literal-block">
class Foo : <em> public    base1 =</em> public    some_base,
            <em> protected base2 =</em> protected another_base,
            <em> private   base3 =</em> private   yet_another_base
{}; 

typedef Foo::base1 base1; // Ok, base1 is a public membr of Foo.
typedef Foo::base3 base3; // ERROR, 'base3' is a private name

class Bar : public Foo
{
    typedef base2 foos_2nd_base; // Ok, base2 is a protected 
                                 // member of Foo.
};
</pre>
<p>
This leaves us with one open question: when the alias definition does not
have an access-specifier, what access do we assign to it? What's the
"sensible default"?  Here are some possible answers to that question:
<ul>
    <li>The default access is always private.  An advantage here is that
    it's impossible for the author of a class to accidentally leave the
    injected name open to inadvertent coupling.)
    </li>
    <li>
    The default access is private if the derived class is declared with
    the class-key 'class' and 'public' otherwise.
    </li>
    <li>The default access is the access of the base class to which the
    alias name refers. For example, this would make the explicit access
    specifiers on base1, base2 and base3 above redundant.
    </li>
</ul>
</p>

</div>
</div>
</div>
</body>
</html>
