cpp.ht

New C++ Features

<h2>Dave's Most Desired C++ Features</h2>

In writing SWIG, I have developed a whole new appreciation for the
language that is C++.  However, I have also come to discover a number
of serious limitations in the language.  Therefore, in the interest of
public service, I now present my semi-official list of C++ features
I would most like to see implemented:

<ul>
<li><b>The slightly ambiguous reference.</b> This would be a variation
on the ever-so-useful C++ reference (&amp;) used to denote a quantity
that refers to either the object itself (by value) to a reference to
an object.  The preferred syntax for this is to enclose the variable
name in brackets and use the ampersand like this
<tt>&lt;&amp;foo&gt;</tt>.

<blockquote>
<pre>
void foo(Bar <&amp;b>) {
    b.frag(3);       // Call some method  
    ...
}
</pre>
</blockquote>

In this case, <tt>foo</tt> would either be passed a copy of a
<tt>Bar</tt> type (pass by value) or a reference to an existing
<tt>Bar</tt>.  The precise choice, of course, would be up to the
implementation.  Obviously, the compiler would pick the best
option--making it a good choice for programmers too stupid to know whether
they should use a pointer or not.
<p>
Obviously, there are a few complicated cases such as:

<blockquote>
<pre>
void foo(const Bar *const *<&amp;b>);
</pre>
</blockquote>

The interpretation of this is left as an exercise to the reader (hey,
it's good to be a professor).

<li><p><b>Circular shift operators.</b> Sure, one doesn't really need to
do a circular bit shift very often, but they are sometimes useful in
cryptographic algorithms and for general-purpose bit-twiddling.  I
propose the inclusion of the triple angle bracket operators
(<tt>&lt;&lt;&lt;</tt> and <tt>&gt;&gt;&gt;</tt>) for this purpose.  Of
course, these operators could also be overloaded just like the normal
shift operators.  It's not that I really need these operators, but it
is yet another opportunity to include more angle brackets into the
language.

<li><p><b>The survival cast.</b>  I'm not really sure where I got this idea,
but basically it works like this: given an object, you can cast it using
a <tt>survival_cast</tt> like this  

<blockquote>
<pre>
Bar *x = survival_cast&lt;Bar *&gt;(y);
</pre>
</blockquote>

Afterwards, the object that <tt>x</tt> points to is guaranteed to be
undeletable--even if a program repeatedly calls <tt>delete</tt> or
<tt>free()</tt> on it.  This effect applies to the object itself, not
the pointer (thus, the cast implicitly applies to all other pointers referring to
the same object).  Furthermore, the cast remains in effect until the
program terminates--making this a particularly good way to avoid those
pesky memory management problems such as calling delete too many times
by accident.

<p>
The survival cast can be applied to the individual elements of an array
or container.  However, in this case, the implementation must ensure
that deletion of the array or container only deletes those members for
which the survival cast has not been applied.

<p>
When too many objects have been cast using the survival cast, they may
decide to spontaneously delete themselves along with an unspecified
number of non-survival objects.  This is a feature.  However, the
precise mechanism and scope of destruction is implementation specific
and may depend on the type of objects to which the survival cast has
been applied.

<li><p><b>The non-castable function pointer</b>.  Since function pointers are
too confusing for everyone, it should be impossible to cast them into any
other type.  Oh wait, this is already a C++ feature.

<li><p><b>The identifier length cast</b>.  Since we're on the subject of casting....  I would
also like to propose the identifier length cast.  This is a cast that only works
if the identifier names of the two types are exactly the same length in 
characters.  For example:

<blockquote>
<pre>
Bar *x = identifier_length_cast&lt;Foo *&gt;(y);     // Ok
FooBar *x = identifier_length_cast&lt;Foo *&gt;(y);  // Error
</pre>
</blockquote>

In addition, there should be an <tt>identifier_case_cast</tt> that works similarly, but
which looks at the case of the type names.   I'm not really sure what purpose these casts
would serve, but that doesn't really distinguish them from any of the other casts.
 
<li><p><b>The instance goto</b>.  In a nutshell, I really want to be able to do
this:

<blockquote>
<pre>
class Foo {
public:
   ...
   bar:
      printf("Hello world\n");
      ... some code here ...
      break;
};

int main() {
    Foo *f = new Foo;
    goto f.bar;
    ...
}
</pre>
</blockquote>
Obviously, the benefits of this feature are self-evident.  However,
there are still a few tricky points.  First, the goto should work with
inheritance when the goto label happens to appear in a base-class.  Second,
the goto should certainly take advantage of dynamic binding much like virtual
member functions.   Finally, I believe that there would be many interesting
possibilities of combining template classes with goto.  For example:

<blockquote>
<pre>
template class Foo&lt;x&gt; {
public:
    x: 
        ... some code here ...
        break;
    ...
};
</pre>
</blockquote>

Clearly, the number of applications is endless.

<li><p><b>MP3 player</b>.   Since compiling a C++ application takes so long, I think
it would be useful to modify the C++ compiler to go out and search the net for an
appropriate symphony or sonata to download and play while it is working. Ahhhh. Yes.
Of course, if you have a DVD player handy, I have personally found that watching "Apocalypse Now"
is a relaxing way to pass the time.

</ul>

Have a further feature suggestion?  Please let me know.