<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: What did we pay for C++ Runtime Polymorphism: Part II</title>
	<atom:link href="http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii/feed" rel="self" type="application/rss+xml" />
	<link>http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii</link>
	<description>Knowledge was arriving in dribs and drabs</description>
	<lastBuildDate>Mon, 30 Aug 2010 05:34:12 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Game degree</title>
		<link>http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii/comment-page-1#comment-75</link>
		<dc:creator>Game degree</dc:creator>
		<pubDate>Tue, 24 Aug 2010 22:23:44 +0000</pubDate>
		<guid isPermaLink="false">http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii#comment-75</guid>
		<description>Lots of extremely reading here, thanks! I had been searching on yahoo when I identified your article, I’m going to add your feed to Google Reader, I look forward to much more from you.</description>
		<content:encoded><![CDATA[<p>Lots of extremely reading here, thanks! I had been searching on yahoo when I identified your article, I’m going to add your feed to Google Reader, I look forward to much more from you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii/comment-page-1#comment-42</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Fri, 01 Jan 2010 19:33:34 +0000</pubDate>
		<guid isPermaLink="false">http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii#comment-42</guid>
		<description>Sorry, pressed submit accidentally :(
Using CRTP, you can eliminate _all_ virtual function calls. Your example, provides a common base class for all the Derived objects, so you had to implement go() as virtual. CRTP is not intended for such cases and is intended where you want to reuse the functionality of base class at most points, but want to customize specific steps in the algo. Consider:

class Base
{
virtual void magic()
{
  chant();
  wave();
  profit();
}

virtual chant(){}
virtual wave(){}
virtual profit(){}
};

Assume there is a derived class, Derived, which overrides only wave(). [we want to use default implementations for all else]
Now, if you are wondering why chant(), wave() and profit() were declared virtual, you cannot customize them unless you declare them as virtual. This is because, once your derived class calls magic(), it calls the Base::magic() [we have not overridden magic() for Derived, we have overridden only wave()]. Then, when it calls wave(), it would have called Base::wave() if it had not been declared virtual. Here, we know that we are using Derived object, but just want to reuse the functionality of Base and we are paying the penalty of virtual due to above mentioned problem. CRTP comes to the rescue in precisely these situation, and you can get rid of _all_ virtual functions. Yes sir, all of them :)</description>
		<content:encoded><![CDATA[<p>Sorry, pressed submit accidentally <img src='http://codegem.org/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' /><br />
Using CRTP, you can eliminate _all_ virtual function calls. Your example, provides a common base class for all the Derived objects, so you had to implement go() as virtual. CRTP is not intended for such cases and is intended where you want to reuse the functionality of base class at most points, but want to customize specific steps in the algo. Consider:</p>
<p>class Base<br />
{<br />
virtual void magic()<br />
{<br />
  chant();<br />
  wave();<br />
  profit();<br />
}</p>
<p>virtual chant(){}<br />
virtual wave(){}<br />
virtual profit(){}<br />
};</p>
<p>Assume there is a derived class, Derived, which overrides only wave(). [we want to use default implementations for all else]<br />
Now, if you are wondering why chant(), wave() and profit() were declared virtual, you cannot customize them unless you declare them as virtual. This is because, once your derived class calls magic(), it calls the Base::magic() [we have not overridden magic() for Derived, we have overridden only wave()]. Then, when it calls wave(), it would have called Base::wave() if it had not been declared virtual. Here, we know that we are using Derived object, but just want to reuse the functionality of Base and we are paying the penalty of virtual due to above mentioned problem. CRTP comes to the rescue in precisely these situation, and you can get rid of _all_ virtual functions. Yes sir, all of them <img src='http://codegem.org/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii/comment-page-1#comment-41</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Fri, 01 Jan 2010 19:13:43 +0000</pubDate>
		<guid isPermaLink="false">http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii#comment-41</guid>
		<description>You could have gotten all the gains by just not declaring doSomething() and doSomethingElse() as non-virtual. This technique is useful for strategy pattern, where the base class defines a generic algorithm whose specific steps are executed by derived classes. In such a case, we can get away with virtual for the implementation steps. 
Eg:

class Base
{
    void algo()
    {
        this-&gt;init();
        //some common stuff
        this-&gt;print();
    }
    
    virtual void init() = 0;
    virtual void print() = 0;
};

class Derived: public Base
{
//implement the specific functions
};

In this case, CRTP can be used to eliminate the need to declare the two implementation functions as virtual.</description>
		<content:encoded><![CDATA[<p>You could have gotten all the gains by just not declaring doSomething() and doSomethingElse() as non-virtual. This technique is useful for strategy pattern, where the base class defines a generic algorithm whose specific steps are executed by derived classes. In such a case, we can get away with virtual for the implementation steps.<br />
Eg:</p>
<p>class Base<br />
{<br />
    void algo()<br />
    {<br />
        this-&gt;init();<br />
        //some common stuff<br />
        this-&gt;print();<br />
    }</p>
<p>    virtual void init() = 0;<br />
    virtual void print() = 0;<br />
};</p>
<p>class Derived: public Base<br />
{<br />
//implement the specific functions<br />
};</p>
<p>In this case, CRTP can be used to eliminate the need to declare the two implementation functions as virtual.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bryan E</title>
		<link>http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii/comment-page-1#comment-10</link>
		<dc:creator>Bryan E</dc:creator>
		<pubDate>Mon, 06 Oct 2008 20:12:55 +0000</pubDate>
		<guid isPermaLink="false">http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii#comment-10</guid>
		<description>You should see the same performance improvement by simply removing &quot;virtual&quot; from the definitions of the two helper functions.  Since these functions are defined as &quot;specific to Derived&quot;, this should not cause problems, and eliminates the unnecessary complexity of using templates.

This may be considered a lesson in &quot;being aware of what should be virtual&quot; versus &quot;make everything virtual, just in case&quot;...</description>
		<content:encoded><![CDATA[<p>You should see the same performance improvement by simply removing &#8220;virtual&#8221; from the definitions of the two helper functions.  Since these functions are defined as &#8220;specific to Derived&#8221;, this should not cause problems, and eliminates the unnecessary complexity of using templates.</p>
<p>This may be considered a lesson in &#8220;being aware of what should be virtual&#8221; versus &#8220;make everything virtual, just in case&#8221;&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jay</title>
		<link>http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii/comment-page-1#comment-8</link>
		<dc:creator>Jay</dc:creator>
		<pubDate>Sun, 05 Oct 2008 16:18:54 +0000</pubDate>
		<guid isPermaLink="false">http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii#comment-8</guid>
		<description>Well actually the performance improvement is not that huge although it looks like so in the post. Becasue I am using some trivial cases to do the test. In real life you got have some code in your methods which will make the function call overhead unnoticeable.:-)</description>
		<content:encoded><![CDATA[<p>Well actually the performance improvement is not that huge although it looks like so in the post. Becasue I am using some trivial cases to do the test. In real life you got have some code in your methods which will make the function call overhead unnoticeable.:-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul</title>
		<link>http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii/comment-page-1#comment-7</link>
		<dc:creator>Paul</dc:creator>
		<pubDate>Sun, 05 Oct 2008 14:41:37 +0000</pubDate>
		<guid isPermaLink="false">http://codegem.org/2008/10/what-did-we-pay-for-c-runtime-polymorphism-part-ii#comment-7</guid>
		<description>Amazing, I never thought we can get the tremendous performance improvement through static polymorphism! You got my vote!</description>
		<content:encoded><![CDATA[<p>Amazing, I never thought we can get the tremendous performance improvement through static polymorphism! You got my vote!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
