The attached patch is the direction I was thinking of. I believe the changes outside APValue are all redundant with this approach; this is a pure optimization of the existing interface. The ExtractSubobject change isn't necessary, but it avoids some potentially-expensive copying. Some care is required to avoid it creating a cyclic value.<div>
<br></div><div>I've not got any performance numbers for this change yet.</div><div><br><div class="gmail_quote">On Wed, Mar 7, 2012 at 5:15 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><div class="gmail_quote">On Wed, Mar 7, 2012 at 3:05 PM, Daniel Dunbar <span dir="ltr"><<a href="mailto:daniel@zuster.org" target="_blank">daniel@zuster.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Here is a patch which adds APValue::swap and uses it.<br>
<br>
I'm not sure I like it, anyone else have an opinion for putting it in or not?<br></blockquote><div> </div></div></div>This was actually something I was intending to investigate soon. A few thoughts:<div><br></div><div>
I'd prefer to see operator= changed as follows, all the code which says 'foo = APValue(...);' left alone:</div>
<div><br></div><div>APValue &operator=(APValue RHS) {</div><div>  swap(RHS);</div><div>  return *this;</div><div>}</div><div><br></div><div>Copy elision will do the rest. I'd then prefer to see copy_from killed, with the implementation moved to APValue's copy constructor (which should then be out-of-line).</div>

<div><div><br></div><div>Do you have any performance numbers for this?</div></div>
</blockquote></div><br></div>