Boost C++ Libraries: Ticket #10080: Make optional copy-ctor https://svn.boost.org/trac10/ticket/10080 <p> I know that coroutines are made movable only to prevent UB during a stack unwinding of RAII objects. But there could be only POD objects and copy-ctor should work perfectly fine ( my scenario is a binary tree iterator that has a coroutine ). </p> <p> So I suggest to make an optional ( via template parameter? ) copy constructor. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/10080 Trac 1.4.3 olli Sat, 31 May 2014 08:14:42 GMT status changed; resolution set https://svn.boost.org/trac10/ticket/10080#comment:1 https://svn.boost.org/trac10/ticket/10080#comment:1 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">invalid</span> </li> </ul> <p> making coroutine copy-able would require to copy the stack. this is dangerous even with POD. you get unexpected behaviour if you copy a stack which has references/pointers to objects on the stack. </p> <pre class="wiki">int i = 0; ... int * j = &amp; i; </pre><p> If you copy the stack above, j of the new (copied-to) stack would contain the address of i of the original (copied-from) stack. </p> Ticket anonymous Thu, 05 Jun 2014 05:33:27 GMT <link>https://svn.boost.org/trac10/ticket/10080#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/10080#comment:2</guid> <description> <p> I agree that API should encourage a right use and discourage a wrong one. But I believe most of boost::coroutine users understand it's basic principles and a potential problem that could arise if the <strong>optional</strong> copy-ctor is being used. So I suggest a little on-my-own-risk freedom. </p> </description> <category>Ticket</category> </item> </channel> </rss>