<div dir="ltr">Hi Guys,<div><br></div><div>Thanks for catching that - I've attached an updated patch. I'm still just testing correctness, rather than implementation specifics, but it does at least verify that it's move-constructing rather than copy-constructing now.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 22, 2015 at 4:19 PM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Thu, Jan 22, 2015 at 4:17 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
> On 2015-Jan-22, at 16:04, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
><br>
> This looks like it's only adding copy, not move - did I miss something?<br>
><br>
> On Thu, Jan 22, 2015 at 3:54 PM, Lang Hames <<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</a>> wrote:<br>
> Hi All,<br>
><br>
> The attached patch adds move-construction and move-assignment from SmallVectorImpl<T> to SmallVector<T, N>. It enables us to move between SmallVectors of different types, which will allow me to fix one of the most commented-upon warts from the new JIT APIs.<br>
><br>
> Unit-test included.<br>
><br>
> Cheers,<br>
> Lang.<br>
><br>
<br>
</span>Yeah, the tests don't actually confirm that the thing was moved.  In<br>
particular, you want to check that whenever the source is in big-mode,<br>
the destination points at the same memory that the source used to (well,<br>
assuming that's the behaviour you want, which the naive implementation<br>
will give you IIUC).<br>
<br>
There's also a "big mode -> small mode" funny state thing that'll happen<br>
with the naive implementation.  I'm not sure it's *wrong*, but...<br>
<br>
Given:<br>
<br>
    SmallVector<int, 1> InBigMode(2);<br>
    SmallVector<int, 2> InBigModeToo = std::move(InBigMode);<br>
<br>
I think this will pass:<br>
<br>
    assert(!InBigModeToo.isSmall());<br>
<br>
This a new state -- a SmallVector can be in "big" mode with a heap<br>
allocation, even though its capacity would fit in its "small" mode<br>
stack allocation.<br>
<br>
While weird, I don't really have a problem with it (but maybe others<br>
do?).  Might be worth testing a few operations in this untested state<br>
though.</blockquote></div></div><div><br>It's probably valuable that this is the outcome - it'd be wasteful to throw away the dynamic allocation (going down to small mode) - better to keep it even though it's < small_size. So I'd be in favor of this. </div></div><br></div></div>
</blockquote></div><br></div>