<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 3, 2014 at 10:10 AM, 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 class=""><br>
> On 2014-Dec-02, at 21:48, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
><br>
> Right - and it's not strictly optimal - if the grow operation was split (allocating the new buffer first, then constructing the newly-inserted element, then moving elements over) it could be done without extra moves. But that's more work.<br>
><br>
> I think my head got sore right about the time I tried to figure out what, if any, guarantees could be given for insertion of a range into itself... when there's no reallocation happening, it's impossible (because you have to move things out of the way first - so you might've broken the range - indeed even a non-range insertion, if the referenced element comes after the insertion point... I can't remember if libc++ (I looked around in there to see how to implement these things, which things were required and which weren't) did some sorcery to handle some subset of those cases - perhaps by building the new element at the end, then swapping it in? I forget)<br>
<br>
</span>FWIW, STL sequences don't allow self-referencing range insertion.  From<br>
n3337, section 23.2.3, Table 100:<br>
<br>
> a.insert(p,i,j)<br>
><br>
> iterator<br>
><br>
> Requires:T shall be EmplaceConstructible into X from *i. For vector, if the iterator does not meet the forward iterator requirements (24.2.5), T shall also be MoveInsertable into X and MoveAssignable. Each iterator in the range [i,j) shall be dereferenced exactly once.<br>
><br>
> pre: i and j are not iterators into a.<br>
> Inserts copies of elements in [i, j) before p<br></blockquote><div><br>Ah, good to know - thanks for the reference. (I probably saw that back when I was looking at this, but it's been a while)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I imagine the rest of it is all fixable, through various sorts of<br>
sorcery, as you mentioned.  The only barrier is running benchmarks to<br>
be sure we don't have any major compile-time regressions.</blockquote></div><br>Possibly - I'm still not quite clear on the non-reallocating case. But I imagine there are ways & means.<br><br></div></div>