    <rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:sy="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
     <channel>
        <title>ACCU  :: QM Bites : Maximising Discoverability of Virtual Methods</title>
        <link>https://members.accu.org/index.php/journals/2202</link>
        <description>Professionalism in Programming</description>
        <dc:language>en-us</dc:language> 
        <dc:creator>Administrator</dc:creator> 
        <admin:generatorAgent rdf:resource="http://www.xaraya.org" /> 
        <admin:errorReportsTo rdf:resource="mailto:webeditor@accu.org" />
       <sy:updatePeriod>hourly</sy:updatePeriod>
       <sy:updateFrequency>1</sy:updateFrequency>
       <docs>http://backend.userland.com/rss</docs>


        <h2>Journal Articles</h2>


<div class="xar-mod-head"><span class="xar-mod-title">Overload Journal #131 - February 2016 + Programming Topics</span></div>

<table border="0" cellpadding="1" cellspacing="0">
    <tbody>
    <tr>
        <td valign="top">
            Browse in :
       </td>
       <td valign="top">

                                            <a href="https://members.accu.org/index.php/journals/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c76/">Journals</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c78/">Overload</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c358/">o131</a>
                    (7)
<br />

                                            <a href="https://members.accu.org/index.php/journals/">All</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c13/">Topics</a>

                     &gt;                         <a href="https://members.accu.org/index.php/journals/c65/">Programming</a>
                    (877)
<br />

                                            <a href="https://members.accu.org/index.php/journals/c358-65/">Any of these categories</a>

                    -                        <a href="https://members.accu.org/index.php/journals/c358+65/">All of these categories</a>
<br />
</td>
   </tr>
   </tbody>
</table>




<div class="xar-error">
   <p>
 <strong>Note:</strong> when you create a new publication type,
the articles module will automatically use the templates
<em>user-display-[publicationtype].xt</em>
and <em>user-summary-[publicationtype].xt</em>.
If those templates do not exist when you try to preview or display a new article,
you'll get this warning :-)  Please place your own templates in themes/<em>yourtheme</em>/modules/articles . The templates will get the extension .xt there. </p>
</div>
<div class="xar-norm xar-standard-box-padding">
   <h1><strong>Title:</strong>&nbsp;QM Bites : Maximising Discoverability of Virtual Methods</h1>
<p><strong>Author:</strong>&nbsp;Martin Moene</p>
<p>
<strong>Date:</strong> 02 February 2016 18:54:29 +00:00 or Tue, 02 February 2016 18:54:29 +00:00</p>
<p><strong>Summary:</strong>&nbsp;C++11 introduced override as a contextual keyword. Matthew Wilson encourages us to use it.</p>
<p><strong>Body:</strong>&nbsp;<h2>TL;DR:</h2>

<p>Reduce opacity in C++ inheritance hierarchies w <code>override</code> k/w (or comments in C++03/earlier)</p>

<h3>Bite:</h3>

<p>One of the myriad sources of confusion about C++â€™s ambiguous syntax is in determining whether or not a virtual function is one prescribed in the type one is currently examining or prescribed from a parent class. Consider the following:</p>

<pre class="programlisting">
  class MidLevel
   : public TopLevel
  {
    . . .
    virtual void SomeMethod();
  };</pre>

<p>There are several possible interpretations:</p>

<ol>
	<li>The virtual method <code>SomeMethod()</code> is defined and implemented only within the class <code>MidLevel</code> (and may be overridden by derived types);?</li>
	
	<li>The virtual method <code>SomeMethod()</code> is defined by the class <code>TopLevel</code> (or one of its ancestors) in which it is pure, so <code>MidLevel::SomeMethod()</code> is (at this level) its one and only definition;?</li>
	
	<li>The virtual method <code>SomeMethod()</code> is defined and implemented by the class <code>TopLevel</code> (or one of its ancestors) so <code>MidLevel::SomeMethod()</code> is an override (which may or may not invoke <code>TopLevel::SomeMethod()</code> in its implementation);?</li>
</ol>

<p>The only way to know is to examine the definition of the class <code>TopLevel</code>, or the definition of (a) parent class of <code>TopLevel</code>, or the definition of (a) grandparent class of <code>TopLevel</code>, or â€¦</p>

<p>Application of the C++ 11 keyword override is a boon to discoverability, in that it connotes that the method is an override of a method declared/defined by a parent class. Hence, Listing 1 implies either case 2 or 3 above.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
class MidLevel
 : public TopLevel
{
  . . .
  virtual void SomeMethod() override;
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 1</td>
	</tr>
</table>

<p>With C++-98/03 (or any compiler that does not support C++ 11â€™s override), an alternative declarative technique is simply to use a comment, as in Listing 2, or object-like pseudo-keyword macro (that resolves to <code>override</code> with compilers that support the keyword, and to nothing with those that do not), as in Listing 3 and Listing 4.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
class MidLevel
 : public TopLevel
{
  . . .
  virtual void SomeMethod() /* override */;
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 2</td>
	</tr>
</table>


<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
#ifdef
  ACMESOFT_COMPILER_SUPPORTS_override_KEYWORD
# define ACMESOFT_override_K    override
#else
# define ACMESOFT_override_K
#endif
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 3</td>
	</tr>
</table>


<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
class MidLevel
 : public TopLevel
{
  . . .
  virtual void SomeMethod() ACMESOFT_override_K;
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 4</td>
	</tr>
</table>

<p>Of course, the virtue of the new keyword is far greater than that of connotation of design intent â€“ it facilitates <em>enforcement</em> of design intent. If Listing 1 is presented to the compiler in case 1, it will be a compiler error, since one cannot override something that does not (previously) exist. Thatâ€™s great.</p>

<p>Just as importantly, it guards against coding errors and/or design changes, in requiring that the overriding method matches the overridden method. If Listing 1 compiles, but then the method signature (or return type, or cv-qualification, or universality) changes in the parent class â€“ the <em>fragile base class</em> problem â€“ it will be a compile error. Thatâ€™s great too.</p>

<p>(Obviously, neither the comment-form nor the macro-form do any enforcement with non-C++-11-compatible compilation, but it still is a non-trivial amount of help for the human side of things.)</p>

<p>Prior to the advent of <code>override</code> my practice was to distinguish between case 1 and cases 2/3 by placing the <code>virtual</code> keyword in comments, as in Listing 5.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
class MidLevel
 : public TopLevel
{
  . . .
  /* virtual */
  void SomeMethod() ACMESOFT_override_K;
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 5</td>
	</tr>
</table>

<p>Should you wish, you may do this too, but since <code>override</code> does a superior job in connoting overriding, you might prefer to elide it completely, as in Listing 6.</p>

<table class="sidebartable">
	<tr>
		<td>
			<pre class="programlisting">
class MidLevel
 : public TopLevel
{
  . . .
  void SomeMethod() ACMESOFT_override_K;
};
			</pre>
		</td>
	</tr>
	<tr>
		<td class="title">Listing 6</td>
	</tr>
</table>

<p>After all this you might be wondering what we do about distinguishing between cases 2 and 3. Thatâ€™s another story (but if I give you a hint and suggest that case 3 is pretty much a design smell, pertaining to <em>modularity</em> as well as <em>discoverability</em>, you might get there before we visit that subject in this place).</p>
</p>
<p><strong>Notes:</strong>&nbsp;</p>
<p><em>More fields may be available via dynamicdata ..</em></p>
</div>
</channel>
</rss>
