Databases
StackOverflow2013
Postsdbo
POC++ Virtual Constructor, without clone()
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POC++ Virtual Constructor, without clone()
    primarykey
    data
    text
    <p>I want to perform "deep copies" of an STL container of <strong>pointers to polymorphic classes</strong>.</p> <p>I know about the <em>Prototype</em> design pattern, implemented by means of the <em>Virtual Ctor Idiom</em>, as explained in the <a href="http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.8" rel="nofollow noreferrer">C++ FAQ Lite, Item 20.8</a>.<br> It is simple and straightforward:</p> <pre><code>struct ABC // Abstract Base Class { virtual ~ABC() {} virtual ABC * clone() = 0; }; struct D1 : public ABC { virtual D1 * clone() { return new D1( *this ); } // Covariant Return Type }; </code></pre> <p>A deep copy is then:</p> <pre><code>for( i = 0; i &lt; oldVector.size(); ++i ) newVector.push_back( oldVector[i]-&gt;clone() ); </code></pre> <h1>Drawbacks</h1> <p>As Andrei Alexandrescu <a href="http://www.informit.com/articles/article.aspx?p=31529&amp;seqNum=5" rel="nofollow noreferrer">states it</a>:</p> <blockquote> <p>The <code>clone()</code> implementation must follow the same pattern in all derived classes; in spite of its repetitive structure, there is no reasonable way to automate defining the <code>clone()</code> member function (beyond macros, that is).</p> </blockquote> <p>Moreover, clients of <code>ABC</code> can possibly do something bad. (I mean, nothing prevents clients to do something bad, so, it <em>will</em> happen.)</p> <h1>Better design?</h1> <p>My question is: is there another way to make an abstract base class clonable without requiring derived classes to write clone-related code? (Helper class? Templates?)</p> <hr> <p>Following is my context. Hopefully, it will help understanding my question.</p> <p>I am designing a class hierarchy to perform operations on a class <code>Image</code>:</p> <pre><code>struct ImgOp { virtual ~ImgOp() {} bool run( Image &amp; ) = 0; }; </code></pre> <p>Image operations are user-defined: clients of the class hierarchy will implement their own classes derived from <code>ImgOp</code>:</p> <pre><code>struct CheckImageSize : public ImgOp { std::size_t w, h; bool run( Image &amp;i ) { return w==i.width() &amp;&amp; h==i.height(); } }; struct CheckImageResolution { ... }; struct RotateImage { ... }; ... </code></pre> <p>Multiple operations can be performed sequentially on an image:</p> <pre><code>bool do_operations( vector&lt; ImgOp* &gt; v, Image &amp;i ) { for_each( v.begin(), v.end(), /* bind2nd( mem_fun( &amp;ImgOp::run ), i ... ) don't remember syntax */ ); } </code></pre> <p>If there are multiple images, the set can be split and shared over several threads. To ensure "thread-safety", each thread must have its <strong>own copy of all operation objects</strong> contained in <code>v</code> -- <code>v</code> becomes a prototype to be deep copied in each thread.</p> <p><strong>Edited:</strong> The thread-safe version uses the Prototype design pattern to enforce copy of <em>pointed-to-objects</em> -- not ptrs:</p> <pre><code>struct ImgOp { virtual ~ImgOp() {} bool run( Image &amp; ) = 0; virtual ImgOp * clone() = 0; // virtual ctor }; struct CheckImageSize : public ImgOp { /* no clone code */ }; struct CheckImageResolution : public ImgOp { /* no clone code */ }; struct RotateImage : public ImgOp { /* no clone code */ }; bool do_operations( vector&lt; ImgOp* &gt; v, Image &amp;i ) { // In another thread vector&lt; ImgOp* &gt; v2; transform( v.begin(), v.end(), // Copy pointed-to- back_inserter( v2 ), mem_fun( &amp;ImgOp::clone ) ); // objects for_each( v.begin(), v.end(), /* bind2nd( mem_fun( &amp;ImgOp::run ), i ... ) don't remember syntax */ ); } </code></pre> <p>This has sense when image operation classes are small: do not serialize accesses to unique instances of <code>ImgOp</code>s, rather provide each thread with their own copies.</p> <p>The hard part is to avoid writers of new <code>ImgOp</code>-derived classes to write any clone-related code. (Because this is implementation detail -- this is why I dismissed Paul's answers with the Curiously Recurring Pattern.)</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USJulien-L
    1. USJulien-L
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POC++ Virtual Constructor, without clone()
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POC++ Virtual Constructor, without clone()
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POC++ Virtual Constructor, without clone()
      1. USTimW
      1. VTFavorite
    1. COI'd argue that it is in fact possible to automate `clone()` (if a bit inelegant): http://nerdland.net/2009/06/covariant-templatized-virtual-copy-constructors/
      singulars
      1. POC++ Virtual Constructor, without clone()
      1. USTyler McHenry
    2. CO@tyler McHenry: But making it automatic would encourage bad usage and then C++ would start looking like Java. I would argue that nearly all usages of clone() are wrong (In the few cases where it is required let people do the work of actually implementing it) as unfortunately it is way to simple to use incorrectly thus leading to bad design and implementation.
      singulars
      1. POC++ Virtual Constructor, without clone()
      1. USMartin York
    3. COwhat's wrong with just defining and using the copy constructor the way it was meant to? As @Martin says, you definitely don't want objects to be arbitrarily cloneable.
      singulars
      1. POC++ Virtual Constructor, without clone()
      1. USjalf
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload