------=_Part_9273_311925958.1436362885725
Content-Type: multipart/alternative;
 boundary="----=_Part_9274_531993779.1436362885725"

------=_Part_9274_531993779.1436362885725
Content-Type: text/plain; charset=UTF-8

Hello,

I propose to add a new member function to the vector class named
unstable_erase().
It would erase an element with O(1) complexity, but the order won't be
preserved.

A possible implementation would be :

iterator vector<T>::unstable_erase (const_iterator iter)
{
  *iter = std::move(back());
  pop_back();
  return iter;
}

So, when it is used in the following example,

int main ()
{
  std::vector<int> v{11,36,42,59};

  std::cout << "Before : ";
  for (auto x : v)
    std::cout << x << ' ';
  std::cout << std::endl;

  v.unstable_erase(v.begin());

  std::cout << "After  : ";
  for (auto x : v)
    std::cout << x;
  std::cout << std::endl;

  return 0;
}

the output would be :
Before : 11 36 42 59
After  : 59 36 42

(I called it unstable_erase because it exists a function called stable_sort
which preserves the order of elements.)

What do you think about it?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_9274_531993779.1436362885725
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br><br>I propose to add a new member function to th=
e vector class named <span style=3D"font-family: courier new,monospace;">un=
stable_erase().<br><font face=3D"arial,sans-serif">It would erase an elemen=
t with O(1) complexity, but the order won't be preserved.</font><br><br><sp=
an style=3D"font-family: arial,sans-serif;">A possible implementation would=
 be :<br></span><br>iterator vector&lt;T&gt;::unstable_erase (const_iterato=
r iter)<br>{<br>&nbsp; *iter =3D std::move(back());<br>&nbsp; pop_back();<b=
r>&nbsp; return iter;<br>}<br><br><span style=3D"font-family: arial,sans-se=
rif;">So, when it is used in the following example,</span><br><br>int main =
()<br>{<br>&nbsp; std::vector&lt;int&gt; v{11,36,42,59};<br><br>&nbsp; std:=
:cout &lt;&lt; "Before : ";<br>&nbsp; for (auto x : v)<br>&nbsp;&nbsp;&nbsp=
; std::cout &lt;&lt; x &lt;&lt; ' ';<br>&nbsp; std::cout &lt;&lt; std::endl=
;<br><br>&nbsp; v.unstable_erase(v.begin());<br><br></span><span style=3D"f=
ont-family: courier new,monospace;"><span style=3D"font-family: courier new=
,monospace;">&nbsp; std::cout &lt;&lt; "After&nbsp; : ";</span></span><br><=
span style=3D"font-family: courier new,monospace;"><span style=3D"font-fami=
ly: courier new,monospace;">&nbsp; for (auto x : v)<br>&nbsp;&nbsp;&nbsp; s=
td::cout &lt;&lt; x;<br>&nbsp; std::cout &lt;&lt; std::endl;<br><br></span>=
&nbsp; return 0;<br>}<br><br><span style=3D"font-family: arial,sans-serif;"=
>the output would be :</span><br>Before : 11 36 42 59<br>After&nbsp; : 59 3=
6 42<br><br><span style=3D"font-family: arial,sans-serif;">(I called it <sp=
an style=3D"font-family: courier new,monospace;">unstable_erase</span> beca=
use it exists a function called <span style=3D"font-family: courier new,mon=
ospace;">stable_sort</span> which preserves the order of elements.)</span><=
br><br><span style=3D"font-family: arial,sans-serif;">What do you think abo=
ut it?<br></span><br></span></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_9274_531993779.1436362885725--
------=_Part_9273_311925958.1436362885725--

.

--047d7b874e5044a168051a5dbc2a
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 8, 2015 at 8:41 AM, <aymeric.pelle@gmail.com> wrote:

> Hello,
>
> I propose to add a new member function to the vector class named
> unstable_erase().
> It would erase an element with O(1) complexity, but the order won't be
> preserved.
>
> A possible implementation would be :
>
> iterator vector<T>::unstable_erase (const_iterator iter)
> {
>   *iter = std::move(back());
>   pop_back();
>   return iter;
> }
>
> So, when it is used in the following example,
>
> int main ()
> {
>   std::vector<int> v{11,36,42,59};
>
>   std::cout << "Before : ";
>   for (auto x : v)
>     std::cout << x << ' ';
>   std::cout << std::endl;
>
>   v.unstable_erase(v.begin());
>
>   std::cout << "After  : ";
>   for (auto x : v)
>     std::cout << x;
>   std::cout << std::endl;
>
>   return 0;
> }
>
> the output would be :
> Before : 11 36 42 59
> After  : 59 36 42
>
> (I called it unstable_erase because it exists a function called
> stable_sort which preserves the order of elements.)
>
> What do you think about it?
>

I think you should add this to your organization's library of utility
functions:

/** \pre !v.empty() */
template <typename T>
typename vector<T>::iterator unstable_erase(vector<T> & v, typename
vector<T>::iterator it)
{
    *it = std::move(v.back());
    v.pop_back();
    return it;
}

Why does this need to be a member if it can be done in terms of the
existing public interface to std::vector?

Zach

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b874e5044a168051a5dbc2a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jul 8, 2015 at 8:41 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:aymeri=
c.pelle@gmail.com" target=3D"_blank">aymeric.pelle@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.=
8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-st=
yle:solid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>I propose to add=
 a new member function to the vector class named <span style=3D"font-family=
:&#39;courier new&#39;,monospace">unstable_erase().<br><font face=3D"arial,=
sans-serif">It would erase an element with O(1) complexity, but the order w=
on&#39;t be preserved.</font><br><br><span style=3D"font-family:arial,sans-=
serif">A possible implementation would be :<br></span><br>iterator vector&l=
t;T&gt;::unstable_erase (const_iterator iter)<br>{<br>=C2=A0 *iter =3D std:=
:move(back());<br>=C2=A0 pop_back();<br>=C2=A0 return iter;<br>}<br><br><sp=
an style=3D"font-family:arial,sans-serif">So, when it is used in the follow=
ing example,</span><br><br>int main ()<br>{<br>=C2=A0 std::vector&lt;int&gt=
; v{11,36,42,59};<br><br>=C2=A0 std::cout &lt;&lt; &quot;Before : &quot;;<b=
r>=C2=A0 for (auto x : v)<br>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; x &lt;&l=
t; &#39; &#39;;<br>=C2=A0 std::cout &lt;&lt; std::endl;<br><br>=C2=A0 v.uns=
table_erase(v.begin());<br><br></span><span style=3D"font-family:&#39;couri=
er new&#39;,monospace"><span style=3D"font-family:&#39;courier new&#39;,mon=
ospace">=C2=A0 std::cout &lt;&lt; &quot;After=C2=A0 : &quot;;</span></span>=
<br><span style=3D"font-family:&#39;courier new&#39;,monospace"><span style=
=3D"font-family:&#39;courier new&#39;,monospace">=C2=A0 for (auto x : v)<br=
>=C2=A0=C2=A0=C2=A0 std::cout &lt;&lt; x;<br>=C2=A0 std::cout &lt;&lt; std:=
:endl;<br><br></span>=C2=A0 return 0;<br>}<br><br><span style=3D"font-famil=
y:arial,sans-serif">the output would be :</span><br>Before : 11 36 42 59<br=
>After=C2=A0 : 59 36 42<br><br><span style=3D"font-family:arial,sans-serif"=
>(I called it <span style=3D"font-family:&#39;courier new&#39;,monospace">u=
nstable_erase</span> because it exists a function called <span style=3D"fon=
t-family:&#39;courier new&#39;,monospace">stable_sort</span> which preserve=
s the order of elements.)</span><br><br><span style=3D"font-family:arial,sa=
ns-serif">What do you think about it?</span></span></div></blockquote><div>=
<br></div>I think you should add this to your organization&#39;s library of=
 utility functions:<div><br></div><div>/** \pre !v.empty() */</div><div>tem=
plate &lt;typename T&gt;<div>typename vector&lt;T&gt;::iterator unstable_er=
ase(vector&lt;T&gt; &amp; v, typename vector&lt;T&gt;::iterator it)<br></di=
v><div>{</div><div>=C2=A0 =C2=A0 *it =3D=C2=A0std::move(v.back());</div><di=
v>=C2=A0 =C2=A0 v.pop_back();</div><div>=C2=A0 =C2=A0 return it;</div><div>=
}</div></div><div><br></div><div>Why does this need to be a member if it ca=
n be done in terms of the existing public interface to std::vector?</div><d=
iv><br></div><div>Zach</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b874e5044a168051a5dbc2a--

.

------=_Part_9403_1864237080.1436366818143
Content-Type: multipart/alternative;
 boundary="----=_Part_9404_446193830.1436366818143"

------=_Part_9404_446193830.1436366818143
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le mercredi 8 juillet 2015 16:12:59 UTC+2, Zach Laine a =C3=A9crit :
>
> I think you should add this to your organization's library of utility=20
> functions:
>
> /** \pre !v.empty() */
> template <typename T>
> typename vector<T>::iterator unstable_erase(vector<T> & v, typename=20
> vector<T>::iterator it)
> {
>     *it =3D std::move(v.back());
>     v.pop_back();
>     return it;
> }
>

Yes, I know I can add it into my code.
=20

>
> Why does this need to be a member if it can be done in terms of the=20
> existing public interface to std::vector?
>

For the same reason making std::vector to have a member function front()=20
whereas you can use begin() : it is convenient.
I exposed this idea here to see if other people (who don't need to converse=
=20
order in vector and use erase()) are interested or concerned by this case.
I agree this is useless if there is no people interested in that.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_9404_446193830.1436366818143
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Le mercredi 8 juillet 2015 16:12:59 UTC+2, Zach La=
ine a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote"><div></div>I think you should add=
 this to your organization's library of utility functions:<div><br></div><d=
iv>/** \pre !v.empty() */</div><div>template &lt;typename T&gt;<div>typenam=
e vector&lt;T&gt;::iterator unstable_erase(vector&lt;T&gt; &amp; v, typenam=
e vector&lt;T&gt;::iterator it)<br></div><div>{</div><div>&nbsp; &nbsp; *it=
 =3D&nbsp;std::move(v.back());</div><div>&nbsp; &nbsp; v.pop_back();</div><=
div>&nbsp; &nbsp; return it;</div><div>}</div></div></div></div></div></blo=
ckquote><div><br>Yes, I know I can add it into my code.<br>&nbsp;</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote"><div><br></div><div>Why does this need to be a member if i=
t can be done in terms of the existing public interface to std::vector?</di=
v></div></div></div></blockquote><div><br>For the same reason making std::v=
ector to have a member function <span style=3D"font-family: courier new,mon=
ospace;">front()</span><font face=3D"arial,sans-serif"> whereas you can use=
 <span style=3D"font-family: courier new,monospace;">begin()</span></font> =
: it is convenient.<br>I exposed this idea here to see if other people (who=
 don't need to converse order in vector and use erase()) are interested or =
concerned by this case.<br>I agree this is useless if there is no people in=
terested in that.<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_9404_446193830.1436366818143--
------=_Part_9403_1864237080.1436366818143--

.

--047d7bb03a92bd3de6051a5e57fc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com> wrote=
:

> I exposed this idea here to see if other people (who don't need to
> converse order in vector and use erase()) are interested or concerned by
> this case.
>

You've provided no motivation why people would want to do such a thing.

The only scenario I can think of is dealing cards, and that just doesn't
come up often enough to be worth standardizing.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bb03a92bd3de6051a5e57fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 8=
 July 2015 at 09:46, Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:aymeric.pelle@gmail.com" target=3D"_blank">aymeric.pelle@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
I exposed this idea here to see if other people (who don&#39;t need to conv=
erse order in vector and use erase()) are interested or concerned by this c=
ase.<br></div></div></blockquote><div><br></div><div>You&#39;ve provided no=
 motivation why people would want to do such a thing.</div><div><br></div><=
div>The only scenario I can think of is dealing cards, and that just doesn&=
#39;t come up often enough to be worth standardizing.</div></div>-- <br><di=
v class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mai=
lto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@evilo=
verlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bb03a92bd3de6051a5e57fc--

.

--001a1134dcc8f3a9e4051a622610
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I know many in the game industry use a variant of this, usually called
erase_with_last_swap(), as O(1) removal of any element is sometimes very
useful. It's always seemed to me like a nice trick to know more than a
candidate for standardization; maybe I'm wrong. It does not smell like a
candidate to become a member function to me, though.

2015-07-08 10:55 GMT-04:00 Nevin Liber <nevin@eviloverlord.com>:

> On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com> wro=
te:
>
>> I exposed this idea here to see if other people (who don't need to
>> converse order in vector and use erase()) are interested or concerned by
>> this case.
>>
>
> You've provided no motivation why people would want to do such a thing.
>
> The only scenario I can think of is dealing cards, and that just doesn't
> come up often enough to be worth standardizing.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a1134dcc8f3a9e4051a622610
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I know many in the game industry use a variant of thi=
s, usually called erase_with_last_swap(), as O(1) removal of any element is=
 sometimes very useful. It&#39;s always seemed to me like a nice trick to k=
now more than a candidate for standardization; maybe I&#39;m wrong. It does=
 not smell like a candidate to become a member function to me, though.<code=
><br></code></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_=
quote">2015-07-08 10:55 GMT-04:00 Nevin Liber <span dir=3D"ltr">&lt;<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div cl=
ass=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On 8 July 2=
015 at 09:46, Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a href=3D"mailto:ay=
meric.pelle@gmail.com" target=3D"_blank">aymeric.pelle@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I expos=
ed this idea here to see if other people (who don&#39;t need to converse or=
der in vector and use erase()) are interested or concerned by this case.<br=
></div></div></blockquote><div><br></div></span><div>You&#39;ve provided no=
 motivation why people would want to do such a thing.</div><div><br></div><=
div>The only scenario I can think of is dealing cards, and that just doesn&=
#39;t come up often enough to be worth standardizing.</div></div><span clas=
s=3D"HOEnZb"><font color=3D"#888888">-- <br><div>=C2=A0Nevin &quot;:-)&quot=
; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=
=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a href=3D"tel:%28847%29%2=
0691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</a></div=
>
</font></span></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1134dcc8f3a9e4051a622610--

.

On 2015-07-08 10:55, Nevin Liber wrote:
> On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com
> <mailto:aymeric.pelle@gmail.com>> wrote:
>=20
>     I exposed this idea here to see if other people (who don't need to
>     converse order in vector and use erase()) are interested or
>     concerned by this case.
>=20
>=20
> You've provided no motivation why people would want to do such a thing.
>=20
> The only scenario I can think of is dealing cards, and that just doesn't
> come up often enough to be worth standardizing.

It's useful because O(1) erase from vectors is often sufficient and can
improve your algorithmic complexity.  Any time when you're using a
vector as just a 'collection of objects' where the order doesn't matter
(but set or unordered_set would be too slow).

It might be worth standardizing because it's a trick people (in my
experience) are often not aware of, and presence in the standard library
would help spread that awareness.

Of course, this applies to any SequenceContainer with pop_back, not just
vector.  And it need not be a member function.

John Bytheway

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--047d7bae44a099d152051a771f6c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I imagine that you mean that it should apply to std::deque, in the case of
std::list that would be a pessimization as removal in the middle is just as
efficient as it is at the end.  I am not sure how much I like the proposal,
it seems to be like something that can live in user space easily enough,
but it could be in the library...

    David

On Thu, Jul 9, 2015 at 2:49 AM, John Bytheway <jbytheway@gmail.com> wrote:

> On 2015-07-08 10:55, Nevin Liber wrote:
> > On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com
> > <mailto:aymeric.pelle@gmail.com>> wrote:
> >
> >     I exposed this idea here to see if other people (who don't need to
> >     converse order in vector and use erase()) are interested or
> >     concerned by this case.
> >
> >
> > You've provided no motivation why people would want to do such a thing.
> >
> > The only scenario I can think of is dealing cards, and that just doesn'=
t
> > come up often enough to be worth standardizing.
>
> It's useful because O(1) erase from vectors is often sufficient and can
> improve your algorithmic complexity.  Any time when you're using a
> vector as just a 'collection of objects' where the order doesn't matter
> (but set or unordered_set would be too slow).
>
> It might be worth standardizing because it's a trick people (in my
> experience) are often not aware of, and presence in the standard library
> would help spread that awareness.
>
> Of course, this applies to any SequenceContainer with pop_back, not just
> vector.  And it need not be a member function.
>
> John Bytheway
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bae44a099d152051a771f6c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I imagine that you mean that it should apply to std::deque=
, in the case of std::list that would be a pessimization as removal in the =
middle is just as efficient as it is at the end.=C2=A0 I am not sure how mu=
ch I like the proposal, it seems to be like something that can live in user=
 space easily enough, but it could be in the library...<div><br></div><div>=
=C2=A0 =C2=A0 David<br><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On Thu, Jul 9, 2015 at 2:49 AM, John Bytheway <span dir=3D"ltr">&lt;<=
a href=3D"mailto:jbytheway@gmail.com" target=3D"_blank">jbytheway@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">O=
n 2015-07-08 10:55, Nevin Liber wrote:<br>
&gt; On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 &lt;<a href=3D"mailto:ayme=
ric.pelle@gmail.com">aymeric.pelle@gmail.com</a><br>
</span><span class=3D"">&gt; &lt;mailto:<a href=3D"mailto:aymeric.pelle@gma=
il.com">aymeric.pelle@gmail.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0I exposed this idea here to see if other people (wh=
o don&#39;t need to<br>
&gt;=C2=A0 =C2=A0 =C2=A0converse order in vector and use erase()) are inter=
ested or<br>
&gt;=C2=A0 =C2=A0 =C2=A0concerned by this case.<br>
&gt;<br>
&gt;<br>
&gt; You&#39;ve provided no motivation why people would want to do such a t=
hing.<br>
&gt;<br>
&gt; The only scenario I can think of is dealing cards, and that just doesn=
&#39;t<br>
&gt; come up often enough to be worth standardizing.<br>
<br>
</span>It&#39;s useful because O(1) erase from vectors is often sufficient =
and can<br>
improve your algorithmic complexity.=C2=A0 Any time when you&#39;re using a=
<br>
vector as just a &#39;collection of objects&#39; where the order doesn&#39;=
t matter<br>
(but set or unordered_set would be too slow).<br>
<br>
It might be worth standardizing because it&#39;s a trick people (in my<br>
experience) are often not aware of, and presence in the standard library<br=
>
would help spread that awareness.<br>
<br>
Of course, this applies to any SequenceContainer with pop_back, not just<br=
>
vector.=C2=A0 And it need not be a member function.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
John Bytheway<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bae44a099d152051a771f6c--

.

------=_Part_79_2051001856.1436489904334
Content-Type: multipart/alternative;
 boundary="----=_Part_80_830895408.1436489904335"

------=_Part_80_830895408.1436489904335
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It sounds like this function could be added to <algorithm> as follows...

namespace std {
template<typename C, typename It>
void unstable_erase(C& container, const It& elt) {
    *elt =3D std::move(container.back());  // OOPS
    container.pop_back();
}
} // namespace std

....except that the line marked "OOPS" will invoke undefined behavior in the=
=20
case that iterator =3D=3D container.end()-1, and as David pointed out, it w=
ill=20
be pessimal in the case that C is std::list (so it needs a partial=20
specialization, which means some additional hairiness in the=20
implementation).

In other words, the pattern here is "relatively simple algorithm, lots of=
=20
hairy little details" =E2=80=94 which is exactly the kind of thing we expec=
t the=20
standard library to provide for us. Don't make everybody reinvent the hairy=
=20
wheel; put a good implementation in the STL and give it to everybody for=20
free!

A more traditional-STL interface for this function would be

namespace std {
template<typename It>
It unstable_remove(const It& begin, const It& end, const It& to_remove) {
    if (to_remove !=3D end) {
        *to_remove =3D std::move(*end);
    }
    return std::prev(to_remove);
}
} // namespace std

to be used as

    auto it =3D v.find(...);
    v.erase(std::unstable_remove(v.begin(), v.end(), it), v.end());


On Thursday, July 9, 2015 at 1:30:19 PM UTC-7, David Rodr=C3=ADguez Ibeas w=
rote:
>
> I imagine that you mean that it should apply to std::deque, in the case o=
f=20
> std::list that would be a pessimization as removal in the middle is just =
as=20
> efficient as it is at the end.  I am not sure how much I like the proposa=
l,=20
> it seems to be like something that can live in user space easily enough,=
=20
> but it could be in the library...
>
>     David
>
> On Thu, Jul 9, 2015 at 2:49 AM, John Bytheway <jbyt...@gmail.com=20
> <javascript:>> wrote:
>
>> On 2015-07-08 10:55, Nevin Liber wrote:
>> > On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeri...@gmail.com=20
>> <javascript:>
>> > <mailto:aymeri...@gmail.com <javascript:>>> wrote:
>> >
>> >     I exposed this idea here to see if other people (who don't need to
>> >     converse order in vector and use erase()) are interested or
>> >     concerned by this case.
>> >
>> >
>> > You've provided no motivation why people would want to do such a thing=
..
>> >
>> > The only scenario I can think of is dealing cards, and that just doesn=
't
>> > come up often enough to be worth standardizing.
>>
>> It's useful because O(1) erase from vectors is often sufficient and can
>> improve your algorithmic complexity.  Any time when you're using a
>> vector as just a 'collection of objects' where the order doesn't matter
>> (but set or unordered_set would be too slow).
>>
>> It might be worth standardizing because it's a trick people (in my
>> experience) are often not aware of, and presence in the standard library
>> would help spread that awareness.
>>
>> Of course, this applies to any SequenceContainer with pop_back, not just
>> vector.  And it need not be a member function.
>>
>> John Bytheway
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_80_830895408.1436489904335
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It sounds like this function could be added to &lt;al=
gorithm&gt; as follows...</div><div><br></div><div><font face=3D"courier ne=
w, monospace">namespace std {</font></div><div><font face=3D"courier new, m=
onospace">template&lt;typename C, typename It&gt;</font></div><font face=3D=
"courier new, monospace">void unstable_erase(C&amp; container, const It&amp=
; elt) {</font><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 *el=
t =3D std::move(container.back()); =C2=A0// OOPS</font></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 container.pop_back();</font></di=
v><div><font face=3D"courier new, monospace">}<br></font><div><font face=3D=
"courier new, monospace">} // namespace std</font><div><br></div><div>...ex=
cept that the line marked &quot;OOPS&quot; will invoke undefined behavior i=
n the case that <font face=3D"courier new, monospace">iterator =3D=3D conta=
iner.end()-1</font>, and as David pointed out, it will be pessimal in the c=
ase that C is std::list (so it needs a partial specialization, which means =
some additional hairiness in the implementation).</div><div><br></div><div>=
In other words, the pattern here is &quot;relatively simple algorithm, lots=
 of hairy little details&quot; =E2=80=94 which is exactly the kind of thing=
 we expect the standard library to provide for us. Don&#39;t make everybody=
 reinvent the hairy wheel; put a good implementation in the STL and give it=
 to everybody for free!</div><div><br></div><div>A more traditional-STL int=
erface for this function would be</div><div><br></div><div><div><font face=
=3D"courier new, monospace">namespace std {</font></div><div><font face=3D"=
courier new, monospace">template&lt;typename It&gt;</font></div><font face=
=3D"courier new, monospace">It unstable_remove(const It&amp; begin, const I=
t&amp; end, const It&amp; to_remove) {</font></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 if (to_remove !=3D end) {<br></font><div><=
font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 *to_remove=
 =3D std::move(*end);</font></div><div><font face=3D"courier new, monospace=
">=C2=A0 =C2=A0 }</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 return std::prev(to_remove);</font></div><div><span style=3D"=
font-family: &#39;courier new&#39;, monospace;">}</span><br></div><div><div=
><font face=3D"courier new, monospace">} // namespace std</font></div></div=
></div><div><font face=3D"arial, sans-serif"><br></font></div><div><font fa=
ce=3D"arial, sans-serif">to be used as</font></div><div><font face=3D"arial=
, sans-serif"><br></font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 auto it =3D v.find(...);</font></div><div><font face=3D"couri=
er new, monospace">=C2=A0 =C2=A0 v.erase(std::unstable_remove(v.begin(), v.=
end(), it), v.end());</font></div><div><br></div><div><br>On Thursday, July=
 9, 2015 at 1:30:19 PM UTC-7, David Rodr=C3=ADguez Ibeas wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I imagine that you mean t=
hat it should apply to std::deque, in the case of std::list that would be a=
 pessimization as removal in the middle is just as efficient as it is at th=
e end.=C2=A0 I am not sure how much I like the proposal, it seems to be lik=
e something that can live in user space easily enough, but it could be in t=
he library...<div><br></div><div>=C2=A0 =C2=A0 David<br><div><br><div class=
=3D"gmail_quote">On Thu, Jul 9, 2015 at 2:49 AM, John Bytheway <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">jbyt...@gmail.com</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><span>On 2015-07-08 10:55, Nevin Li=
ber wrote:<br>
&gt; On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 &lt;<a href=3D"javascript:=
" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">aymeri...@gmail.com</a><br>
</span><span>&gt; &lt;mailto:<a href=3D"javascript:" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">aymeri...@gmai=
l.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0I exposed this idea here to see if other people (wh=
o don&#39;t need to<br>
&gt;=C2=A0 =C2=A0 =C2=A0converse order in vector and use erase()) are inter=
ested or<br>
&gt;=C2=A0 =C2=A0 =C2=A0concerned by this case.<br>
&gt;<br>
&gt;<br>
&gt; You&#39;ve provided no motivation why people would want to do such a t=
hing.<br>
&gt;<br>
&gt; The only scenario I can think of is dealing cards, and that just doesn=
&#39;t<br>
&gt; come up often enough to be worth standardizing.<br>
<br>
</span>It&#39;s useful because O(1) erase from vectors is often sufficient =
and can<br>
improve your algorithmic complexity.=C2=A0 Any time when you&#39;re using a=
<br>
vector as just a &#39;collection of objects&#39; where the order doesn&#39;=
t matter<br>
(but set or unordered_set would be too slow).<br>
<br>
It might be worth standardizing because it&#39;s a trick people (in my<br>
experience) are often not aware of, and presence in the standard library<br=
>
would help spread that awareness.<br>
<br>
Of course, this applies to any SequenceContainer with pop_back, not just<br=
>
vector.=C2=A0 And it need not be a member function.<br>
<span><font color=3D"#888888"><br>
John Bytheway<br>
</font></span><div><div><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_80_830895408.1436489904335--
------=_Part_79_2051001856.1436489904334--

.

------=_Part_1661_747144962.1436519833495
Content-Type: multipart/alternative;
 boundary="----=_Part_1662_913149977.1436519833495"

------=_Part_1662_913149977.1436519833495
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


>
> It sounds like this function could be added to <algorithm> as follows...
>
> namespace std {
> template<typename C, typename It>
> void unstable_erase(C& container, const It& elt) {
>     *elt =3D std::move(container.back());  // OOPS
>     container.pop_back();
> }
> } // namespace std
>
> ...except that the line marked "OOPS" will invoke undefined behavior in=
=20
> the case that iterator =3D=3D container.end()-1,=20
>

There is no problem with this line.
When you implement operator=3D (const T& t) for a class, you have to manage=
=20
the case where &t =3D=3D this.
It is the same with r-values, you have to manage this case anyway. You can=
=20
imagine an algorithm where this can happen.
Standard library types manage this case.
From my part, the behavior is not undefined. If it is, the user did a=20
mistake.
=20

> and as David pointed out, it will be pessimal in the case that C is=20
> std::list (so it needs a partial specialization, which means some=20
> additional hairiness in the implementation).
>

A specialization is necessary for std::list which simply calls=20
a_list.erase(an_iterator).
=20

> In other words, the pattern here is "relatively simple algorithm, lots of=
=20
> hairy little details" =E2=80=94 which is exactly the kind of thing we exp=
ect the=20
> standard library to provide for us. Don't make everybody reinvent the hai=
ry=20
> wheel; put a good implementation in the STL and give it to everybody for=
=20
> free!
>
> A more traditional-STL interface for this function would be
>
> namespace std {
> template<typename It>
> It unstable_remove(const It& begin, const It& end, const It& to_remove) {
>     if (to_remove !=3D end) {
>         *to_remove =3D std::move(*end);
>     }
>     return std::prev(to_remove);
> }
> } // namespace std
>

(This function should return std::prev(end).)
I desapprove such a solution. remove functions of the standard take a value=
=20
or a predicate not an iterator. It could be confusing.
Moreover, this function should not test any condition on the input=20
parameters. I prefer a pre-condition as Zach Laine suggested.
Such conditions exist in the standard, for example : 'Calling pop_back on=
=20
an empty container is undefined.'=20
(http://en.cppreference.com/w/cpp/container/vector/pop_back)
=20

>
> to be used as
>
>     auto it =3D v.find(...);
>     v.erase(std::unstable_remove(v.begin(), v.end(), it), v.end());
>

In this case, I would prefer call :

*it =3D std::move(v.back());
v.pop_back();

So, I prefer such an implementation for the generic case :

namespace std {
/**
   \pre !container.empty()
*/
template<typename C, typename It>
It unstable_erase(C& container, const It& iter) {
    *iter =3D std::move(container.back());  // No problem here
    container.pop_back();
    return iter;
}
} // namespace std

For the motivation of this feature, I think John Bytheway and Patrice Roy=
=20
summarised what I had in mind. (Thank you.)
(I have hesitated to submit it for a year. Then, two days ago, I met an=20
other developper in my company who decided to use a list instead of using a=
=20
vector just because
erase has O(1) as complexity for list and not for vector (the order didn't=
=20
matter in his case). Of course, he was not the first developper I met who=
=20
did this mistake.)=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1662_913149977.1436519833495
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>It sound=
s like this function could be added to &lt;algorithm&gt; as follows...</div=
><div><br></div><div><font face=3D"courier new, monospace">namespace std {<=
/font></div><div><font face=3D"courier new, monospace">template&lt;typename=
 C, typename It&gt;</font></div><font face=3D"courier new, monospace">void =
unstable_erase(C&amp; container, const It&amp; elt) {</font><div><font face=
=3D"courier new, monospace">=C2=A0 =C2=A0 *elt =3D std::move(container.back=
()); =C2=A0// OOPS</font></div><div><font face=3D"courier new, monospace">=
=C2=A0 =C2=A0 container.pop_back();</font></div><div><font face=3D"courier =
new, monospace">}<br></font><div><font face=3D"courier new, monospace">} //=
 namespace std</font><div><br></div><div>...except that the line marked &qu=
ot;OOPS&quot; will invoke undefined behavior in the case that <font face=3D=
"courier new, monospace">iterator =3D=3D container.end()-1</font>, </div></=
div></div></div></blockquote><div><br>There is no problem with this line.<b=
r>When you implement <span style=3D"font-family: courier new,monospace;">op=
erator=3D</span> <span style=3D"font-family: courier new,monospace;">(const=
 T&amp; t)</span> for a class, you have to manage the case where &amp;t =3D=
=3D this.<br>It is the same with r-values, you have to manage this case any=
way. You can imagine an algorithm where this can happen.<br>Standard librar=
y types manage this case.<br>From my part, the behavior is not undefined. I=
f it is, the user did a mistake.<br>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div><div>and as David pointed out,=
 it will be pessimal in the case that C is std::list (so it needs a partial=
 specialization, which means some additional hairiness in the implementatio=
n).</div></div></div></div></blockquote><div><br>A specialization is necess=
ary for std::list which simply calls <span style=3D"font-family: courier ne=
w,monospace;">a_list.erase(an_iterator)</span>.<br></div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div><div=
></div><div>In other words, the pattern here is &quot;relatively simple alg=
orithm, lots of hairy little details&quot; =E2=80=94 which is exactly the k=
ind of thing we expect the standard library to provide for us. Don&#39;t ma=
ke everybody reinvent the hairy wheel; put a good implementation in the STL=
 and give it to everybody for free!</div><div><br></div><div>A more traditi=
onal-STL interface for this function would be</div><div><br></div><div><div=
><font face=3D"courier new, monospace">namespace std {</font></div><div><fo=
nt face=3D"courier new, monospace">template&lt;typename It&gt;</font></div>=
<font face=3D"courier new, monospace">It unstable_remove(const It&amp; begi=
n, const It&amp; end, const It&amp; to_remove) {</font></div><div><font fac=
e=3D"courier new, monospace">=C2=A0 =C2=A0 if (to_remove !=3D end) {<br></f=
ont><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
*to_remove =3D std::move(*end);</font></div><div><font face=3D"courier new,=
 monospace">=C2=A0 =C2=A0 }</font></div><div><font face=3D"courier new, mon=
ospace">=C2=A0 =C2=A0 return std::prev(to_remove);</font></div><div><span s=
tyle=3D"font-family:&#39;courier new&#39;,monospace">}</span><br></div><div=
><div><font face=3D"courier new, monospace">} // namespace std</font></div>=
</div></div></div></div></div></blockquote><div><br>(This function should r=
eturn <span style=3D"font-family: courier new,monospace;">std::prev(end)</s=
pan>.)<br>I desapprove such a solution. remove functions of the standard ta=
ke a value or a predicate not an iterator. It could be confusing.<br>Moreov=
er, this function should not test any condition on the input parameters. I =
prefer a pre-condition as Zach Laine suggested.<br>Such conditions exist in=
 the standard, for example : &#39;Calling <code>pop_back</code> on an empty=
 container is undefined.&#39; (http://en.cppreference.com/w/cpp/container/v=
ector/pop_back)<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr"><div><div><div><font face=3D"arial, sans-serif"><br></fon=
t></div><div><font face=3D"arial, sans-serif">to be used as</font></div><di=
v><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"cour=
ier new, monospace">=C2=A0 =C2=A0 auto it =3D v.find(...);</font></div><div=
><font face=3D"courier new, monospace">=C2=A0 =C2=A0 v.erase(std::unstable_=
remove(v.begin(), v.end(), it), v.end());</font></div></div></div></div></b=
lockquote><div><br>In this case, I would prefer call :<br><br><span style=
=3D"font-family: courier new,monospace;">*it =3D std::move(v.back());<br>v.=
pop_back();</span><br><br>So, I prefer such an implementation for the gener=
ic case :<br><br><div><font face=3D"courier new, monospace">namespace std {=
<br></font><div><span style=3D"font-family: courier new,monospace;">/**<br>=
=C2=A0=C2=A0 \pre !</span><span style=3D"font-family: courier new,monospace=
;"><font face=3D"courier new, monospace">container</font>.empty()<br>*/</sp=
an><br></div></div><div><font face=3D"courier new, monospace">template&lt;t=
ypename C, typename It&gt;</font></div><font face=3D"courier new, monospace=
">It unstable_erase(C&amp; container, const It&amp; iter) {</font><div><fon=
t face=3D"courier new, monospace">=C2=A0 =C2=A0 *</font><font face=3D"couri=
er new, monospace"><font face=3D"courier new, monospace">iter</font> =3D st=
d::move(container.back()); =C2=A0// No problem here<br></font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 container.pop_back();<br>=
=C2=A0=C2=A0=C2=A0 return iter;<br></font></div><font face=3D"courier new, =
monospace">}<br></font><font face=3D"courier new, monospace">} // namespace=
 std</font><br><br>For the motivation of this feature, I think <span class=
=3D"_username"><span style=3D"color: rgb(34, 34, 34);" class=3D"LOFA24-D-a"=
><span style=3D"font-weight: normal;">John</span> <span style=3D"font-weigh=
t: normal;">Bytheway</span></span></span> and Patrice Roy summarised what I=
 had in mind. (Thank you.)<br>(I have hesitated to submit it for a year. Th=
en, two days ago, I met an other developper in my company who decided to us=
e a list instead of using a vector just because<br>erase has O(1) as comple=
xity for list and not for vector (the order didn&#39;t matter in his case).=
 Of course, he was not the first developper I met who did this mistake.) <b=
r><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1662_913149977.1436519833495--
------=_Part_1661_747144962.1436519833495--

.

--001a11403efa98b278051a82894e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

2015-07-10 17:17 GMT+08:00 Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com>:
>
> So, I prefer such an implementation for the generic case :
>
> namespace std {
> /**
>    \pre !container.empty()
> */
> template<typename C, typename It>
> It unstable_erase(C& container, const It& iter) {
>     *iter =3D std::move(container.back());  // No problem here
>     container.pop_back();
>     return iter;
> }
> } // namespace std
>
> For the motivation of this feature, I think John Bytheway and Patrice Roy
> summarised what I had in mind. (Thank you.)
> (I have hesitated to submit it for a year. Then, two days ago, I met an
> other developper in my company who decided to use a list instead of using=
 a
> vector just because
> erase has O(1) as complexity for list and not for vector (the order didn'=
t
> matter in his case). Of course, he was not the first developper I met who
> did this mistake.)
>

You'd better prevent self-assignment when iter points to the last element.
BTW, STL has proposed some uniform container erasure interface:
http://en.cppreference.com/w/cpp/experimental/lib_extensions_2#Uniform_cont=
ainer_erasure

I'd like to see unstable_erase be one of them :)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11403efa98b278051a82894e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2015=
-07-10 17:17 GMT+08:00 Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a href=3D"=
mailto:aymeric.pelle@gmail.com" target=3D"_blank">aymeric.pelle@gmail.com</=
a>&gt;</span>:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex"><div>So, I prefer such an implementation for=
 the generic case :<br><br><div><font face=3D"courier new, monospace">names=
pace std {<br></font><div><span style=3D"font-family:&#39;courier new&#39;,=
monospace">/**<br>=C2=A0=C2=A0 \pre !</span><span style=3D"font-family:&#39=
;courier new&#39;,monospace"><font face=3D"courier new, monospace">containe=
r</font>.empty()<br>*/</span><br></div></div><span class=3D""><div><font fa=
ce=3D"courier new, monospace">template&lt;typename C, typename It&gt;</font=
></div></span><font face=3D"courier new, monospace">It unstable_erase(C&amp=
; container, const It&amp; iter) {</font><div><font face=3D"courier new, mo=
nospace">=C2=A0 =C2=A0 *</font><font face=3D"courier new, monospace"><font =
face=3D"courier new, monospace">iter</font> =3D std::move(container.back())=
; =C2=A0// No problem here<br></font></div><div><font face=3D"courier new, =
monospace">=C2=A0 =C2=A0 container.pop_back();<br>=C2=A0=C2=A0=C2=A0 return=
 iter;<br></font></div><font face=3D"courier new, monospace">}<br></font><f=
ont face=3D"courier new, monospace">} // namespace std</font><br><br>For th=
e motivation of this feature, I think <span><span style=3D"color:rgb(34,34,=
34)"><span style=3D"font-weight:normal">John</span> <span style=3D"font-wei=
ght:normal">Bytheway</span></span></span> and Patrice Roy summarised what I=
 had in mind. (Thank you.)<br>(I have hesitated to submit it for a year. Th=
en, two days ago, I met an other developper in my company who decided to us=
e a list instead of using a vector just because<br>erase has O(1) as comple=
xity for list and not for vector (the order didn&#39;t matter in his case).=
 Of course, he was not the first developper I met who did this mistake.) <b=
r></div></blockquote><div><br></div><div>You&#39;d better prevent self-assi=
gnment when iter points to the last element.</div><div>BTW, STL has propose=
d some uniform container erasure interface:</div><div><a href=3D"http://en.=
cppreference.com/w/cpp/experimental/lib_extensions_2#Uniform_container_eras=
ure">http://en.cppreference.com/w/cpp/experimental/lib_extensions_2#Uniform=
_container_erasure</a><br></div><div><br></div><div>I&#39;d like to=C2=A0se=
e unstable_erase be one of them :)</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11403efa98b278051a82894e--

.

--047d7b472548a6744e051a8495c2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 10, 2015 at 2:17 AM, Aymeric Pell=C3=A9 <aymeric.pelle@gmail.co=
m>
wrote:

> It sounds like this function could be added to <algorithm> as follows...
>>
>> namespace std {
>> template<typename C, typename It>
>> void unstable_erase(C& container, const It& elt) {
>>     *elt =3D std::move(container.back());  // OOPS
>>     container.pop_back();
>> }
>> } // namespace std
>>
>> ...except that the line marked "OOPS" will invoke undefined behavior in
>> the case that iterator =3D=3D container.end()-1,
>>
>
> There is no problem with this line.
> When you implement operator=3D (const T& t) for a class, you have to mana=
ge
> the case where &t =3D=3D this.
> It is the same with r-values, you have to manage this case anyway. You ca=
n
> imagine an algorithm where this can happen.
>

I tend to agree with your opinion in general...


> Standard library types manage this case.
>

....Sadly, they *explicitly* do not.  x =3D std::move(x) is *always* undefin=
ed
behavior, when x is a standard library type.
See my C++Now talk, whenever it hits YouTube; or any of the myriad
questions on the subject on StackOverflow.
Let's not derail this thread with the details.


>
>> and as David pointed out, it will be pessimal in the case that C is
>> std::list (so it needs a partial specialization, which means some
>> additional hairiness in the implementation).
>>
>
> A specialization is necessary for std::list which simply calls
> a_list.erase(an_iterator).
>

Right; and this has to be a *partial* specialization for std::list<T>,
which means you'll have to implement it using a helper class, because
function templates can't be partially specialized. That's the hairy detail
to which I referred.
However, unless std::remove is already specialized for std::list<T>, I
don't think unstable_remove should be specialized in that way; the
asymmetry would be more confusing than helpful, and it would eliminate the
possibility of using unstable_remove-without-the-subsequent-erase as a
partitioning algorithm...

*Wait a minute!*

The proposed unstable_remove algorithm is *precisely* std::partition!
http://en.cppreference.com/w/cpp/algorithm/partition

Adding overloads of remove and partition that take specific iterators might
be a separate task worthy of a proposal.
http://en.cppreference.com/w/cpp/algorithm/remove
It's not hard to wrap an iterator in a Predicate, but it's a bit annoying
and fiddly, and changes the complexity of the algorithm from O(1) to O(N)
because now you have to touch all the items in the list to compare them
with your original iterator.

auto it =3D v.find(...);

v.erase(std::partition(v.begin(), v.end(), it), v.end());
  // O(1), could be proposed for standardization

v.erase(std::partition(v.begin(), v.end(), [&](auto& elt) { return &elt =3D=
=3D
&*it; });
  // O(N), already standardized

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b472548a6744e051a8495c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Jul 10, 2015 at 2:17 AM, Aymeric Pell=C3=A9 <span =
dir=3D"ltr">&lt;<a href=3D"mailto:aymeric.pelle@gmail.com" target=3D"_blank=
">aymeric.pelle@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extr=
a"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><span class=3D""><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex"><div dir=3D"ltr"><div>It sounds like this function could be added to =
&lt;algorithm&gt; as follows...</div><div><br></div><div><font face=3D"cour=
ier new, monospace">namespace std {</font></div><div><font face=3D"courier =
new, monospace">template&lt;typename C, typename It&gt;</font></div><font f=
ace=3D"courier new, monospace">void unstable_erase(C&amp; container, const =
It&amp; elt) {</font><div><font face=3D"courier new, monospace">=C2=A0 =C2=
=A0 *elt =3D std::move(container.back()); =C2=A0// OOPS</font></div><div><f=
ont face=3D"courier new, monospace">=C2=A0 =C2=A0 container.pop_back();</fo=
nt></div><div><font face=3D"courier new, monospace">}<br></font><div><font =
face=3D"courier new, monospace">} // namespace std</font><div><br></div><di=
v>...except that the line marked &quot;OOPS&quot; will invoke undefined beh=
avior in the case that <font face=3D"courier new, monospace">iterator =3D=
=3D container.end()-1</font>, </div></div></div></div></blockquote></span><=
div><br>There is no problem with this line.<br>When you implement <span sty=
le=3D"font-family:&#39;courier new&#39;,monospace">operator=3D</span> <span=
 style=3D"font-family:&#39;courier new&#39;,monospace">(const T&amp; t)</sp=
an> for a class, you have to manage the case where &amp;t =3D=3D this.<br>I=
t is the same with r-values, you have to manage this case anyway. You can i=
magine an algorithm where this can happen.<br></div></blockquote><div><br><=
/div><div>I tend to agree with your opinion in general...</div><div>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div>Standard library types manage this case.<br></di=
v></blockquote><div><br></div><div>...Sadly, they <b>explicitly</b> do not.=
 =C2=A0x =3D std::move(x) is <b>always</b> undefined behavior, when x is a =
standard library type.</div><div>See my C++Now talk, whenever it hits YouTu=
be; or any of the myriad questions on the subject on StackOverflow.</div><d=
iv>Let&#39;s not derail this thread with the details.</div><div><br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div>=C2=A0</div><span class=3D""><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-lef=
t-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div><div>and as David pointed out, it will be pessimal in th=
e case that C is std::list (so it needs a partial specialization, which mea=
ns some additional hairiness in the implementation).</div></div></div></div=
></blockquote></span><div><br>A specialization is necessary for std::list w=
hich simply calls <span style=3D"font-family:&#39;courier new&#39;,monospac=
e">a_list.erase(an_iterator)</span>.<br></div></blockquote><div><br></div><=
div>Right; and this has to be a <b>partial</b> specialization for std::list=
&lt;T&gt;, which means you&#39;ll have to implement it using a helper class=
, because function templates can&#39;t be partially specialized. That&#39;s=
 the hairy detail to which I referred.</div><div>However, unless <font face=
=3D"monospace, monospace">std::remove</font> is already specialized for <fo=
nt face=3D"monospace, monospace">std::list&lt;T&gt;</font>, I don&#39;t thi=
nk <font face=3D"monospace, monospace">unstable_remove</font> should be spe=
cialized in that way; the asymmetry would be more confusing than helpful, a=
nd it would eliminate the possibility of using <font face=3D"monospace, mon=
ospace">unstable_remove</font>-without-the-subsequent-<font face=3D"monospa=
ce, monospace">erase</font> as a partitioning algorithm...</div><div><br></=
div><div><i><b>Wait a minute!</b></i></div><div><br></div><div>The proposed=
 unstable_remove algorithm is <i>precisely</i> <font face=3D"monospace, mon=
ospace">std::partition</font>!</div><div><a href=3D"http://en.cppreference.=
com/w/cpp/algorithm/partition">http://en.cppreference.com/w/cpp/algorithm/p=
artition<br></a></div><div><br></div><div>Adding overloads of <font face=3D=
"monospace, monospace">remove</font>=C2=A0and=C2=A0<font face=3D"monospace,=
 monospace">partition</font>=C2=A0that take specific iterators might be a s=
eparate task worthy of a proposal.<br></div><div><a href=3D"http://en.cppre=
ference.com/w/cpp/algorithm/remove">http://en.cppreference.com/w/cpp/algori=
thm/remove</a><br></div><div>It&#39;s not hard to wrap an iterator in a Pre=
dicate, but it&#39;s a bit annoying and fiddly, and changes the complexity =
of the algorithm from O(1) to O(N) because now you have to touch all the it=
ems in the list to compare them with your original iterator.</div><div><br>=
</div><div><font face=3D"monospace, monospace">auto it =3D v.find(...);</fo=
nt></div><div><font face=3D"monospace, monospace"><br></font></div><div><fo=
nt face=3D"monospace, monospace">v.erase(std::partition(v.begin(), v.end(),=
 it), v.end());</font></div><div><font face=3D"monospace, monospace">=C2=A0=
=C2=A0// O(1), could be proposed for standardization</font></div><div><font=
 face=3D"monospace, monospace"><br></font></div><div><font face=3D"monospac=
e, monospace">v.erase(std::partition(v.begin(), v.end(), [&amp;](auto&amp; =
elt) { return &amp;elt =3D=3D &amp;*it; });</font></div><div><font face=3D"=
monospace, monospace">=C2=A0=C2=A0// O(N), already standardized</font></div=
><div><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b472548a6744e051a8495c2--

.

--047d7b472548d08697051a867dd4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 10, 2015 at 5:33 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

>
> *Wait a minute!*
>
> The proposed unstable_remove algorithm is *precisely* std::partition!
> http://en.cppreference.com/w/cpp/algorithm/partition
>
> Adding overloads of remove and partition that take specific iterators
> might be a separate task worthy of a proposal.
> http://en.cppreference.com/w/cpp/algorithm/remove
> It's not hard to wrap an iterator in a Predicate, but it's a bit annoying
> and fiddly, and changes the complexity of the algorithm from O(1) to O(N)
> because now you have to touch all the items in the list to compare them
> with your original iterator.
>
> auto it =3D v.find(...);
>
> v.erase(std::partition(v.begin(), v.end(), it), v.end());
>   // O(1), could be proposed for standardization
>
> v.erase(std::partition(v.begin(), v.end(), [&](auto& elt) { return &elt =
=3D=3D
> &*it; });
>   // O(N), already standardized
>

Of course I meant return &elt *!=3D* &*it on the line above.  Bother.

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b472548d08697051a867dd4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Fri, Jul 10, 2015 at 5:33 AM, Arthur O&#39;Dwyer <span =
dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_bla=
nk">arthur.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><div><br>=
</div></span><div><i><b>Wait a minute!</b></i></div><div><br></div><div>The=
 proposed unstable_remove algorithm is <i>precisely</i> <font face=3D"monos=
pace, monospace">std::partition</font>!</div><div><a href=3D"http://en.cppr=
eference.com/w/cpp/algorithm/partition" target=3D"_blank">http://en.cpprefe=
rence.com/w/cpp/algorithm/partition<br></a></div><div><br></div><div>Adding=
 overloads of <font face=3D"monospace, monospace">remove</font>=C2=A0and=C2=
=A0<font face=3D"monospace, monospace">partition</font>=C2=A0that take spec=
ific iterators might be a separate task worthy of a proposal.<br></div><div=
><a href=3D"http://en.cppreference.com/w/cpp/algorithm/remove" target=3D"_b=
lank">http://en.cppreference.com/w/cpp/algorithm/remove</a><br></div><div>I=
t&#39;s not hard to wrap an iterator in a Predicate, but it&#39;s a bit ann=
oying and fiddly, and changes the complexity of the algorithm from O(1) to =
O(N) because now you have to touch all the items in the list to compare the=
m with your original iterator.</div><div><br></div><div><font face=3D"monos=
pace, monospace">auto it =3D v.find(...);</font></div><div><font face=3D"mo=
nospace, monospace"><br></font></div><div><font face=3D"monospace, monospac=
e">v.erase(std::partition(v.begin(), v.end(), it), v.end());</font></div><d=
iv><font face=3D"monospace, monospace">=C2=A0=C2=A0// O(1), could be propos=
ed for standardization</font></div><div><font face=3D"monospace, monospace"=
><br></font></div><div><font face=3D"monospace, monospace">v.erase(std::par=
tition(v.begin(), v.end(), [&amp;](auto&amp; elt) { return &amp;elt =3D=3D =
&amp;*it; });</font></div><div><font face=3D"monospace, monospace">=C2=A0=
=C2=A0// O(N), already standardized</font></div></div></div></div></blockqu=
ote><div><br></div><div>Of course I meant=C2=A0<span style=3D"font-family:m=
onospace,monospace">return &amp;elt <b>!=3D</b> &amp;*it</span>=C2=A0on the=
 line above.=C2=A0 Bother.</div><div><br></div><div>=E2=80=93Arthur</div></=
div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b472548d08697051a867dd4--

.

--089e01494654b11658051a8712b8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> The proposed unstable_remove algorithm is *precisely* std::partition!


Partition isn't exactly the same as unstable_remove, but they are ever so
almost the same.

In partition, we swap the elements. This leaves objects on both sides of
the partition point in a well-defined state.

unordered_remove would move-assign elements, leaving objects on the right
side of the partition point in a valid but unspecified state as per the
MoveAssignable post condition and as per the remove algorithms.

In the implementation of partition on cppreference, instead of
std::iter_swap(first++, last); it would be first++ =3D std::move(last);

For many types, move-assignment may be implemented in terms of swap so the
difference is negligible. However for something like int, swap does more
work than is necessary.

On Fri, Jul 10, 2015 at 9:50 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
wrote:

> On Fri, Jul 10, 2015 at 5:33 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m
> > wrote:
>
>>
>> *Wait a minute!*
>>
>> The proposed unstable_remove algorithm is *precisely* std::partition!
>> http://en.cppreference.com/w/cpp/algorithm/partition
>>
>> Adding overloads of remove and partition that take specific iterators
>> might be a separate task worthy of a proposal.
>> http://en.cppreference.com/w/cpp/algorithm/remove
>> It's not hard to wrap an iterator in a Predicate, but it's a bit annoyin=
g
>> and fiddly, and changes the complexity of the algorithm from O(1) to O(N=
)
>> because now you have to touch all the items in the list to compare them
>> with your original iterator.
>>
>> auto it =3D v.find(...);
>>
>> v.erase(std::partition(v.begin(), v.end(), it), v.end());
>>   // O(1), could be proposed for standardization
>>
>> v.erase(std::partition(v.begin(), v.end(), [&](auto& elt) { return &elt
>> =3D=3D &*it; });
>>   // O(N), already standardized
>>
>
> Of course I meant return &elt *!=3D* &*it on the line above.  Bother.
>
> =E2=80=93Arthur
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e01494654b11658051a8712b8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span style=3D"font-size:12.8000001907349=
px">The proposed unstable_remove algorithm is=C2=A0</span><i style=3D"font-=
size:12.8000001907349px">precisely</i><span style=3D"font-size:12.800000190=
7349px">=C2=A0</span><font face=3D"monospace, monospace" style=3D"font-size=
:12.8000001907349px">std::partition</font><span style=3D"font-size:12.80000=
01907349px">!</span></blockquote><div>=C2=A0</div>Partition isn&#39;t exact=
ly the same as unstable_remove, but they are ever so almost the same.<div><=
br></div><div>In partition, we swap the elements. This leaves objects on bo=
th sides of the partition point in a well-defined state.</div><div><br></di=
v><div>unordered_remove would move-assign elements, leaving objects on the =
right side of the partition point in a valid but unspecified state as per t=
he MoveAssignable post condition and as per the remove algorithms.</div><di=
v><br></div><div>In the implementation of partition on cppreference, instea=
d of std::iter_swap(first++, last); it would be first++ =3D std::move(last)=
;</div><div><br></div><div>For many types, move-assignment may be implement=
ed in terms of swap so the difference is negligible. However for something =
like int, swap does more work than is necessary.</div></div><div class=3D"g=
mail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 10, 2015 at 9:50 AM,=
 Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.odwyer=
@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On F=
ri, Jul 10, 2015 at 5:33 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@g=
mail.com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><span class=3D""><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2=
04,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div=
 class=3D"gmail_extra"><div class=3D"gmail_quote"><span><div><br></div></sp=
an><div><i><b>Wait a minute!</b></i></div><div><br></div><div>The proposed =
unstable_remove algorithm is <i>precisely</i> <font face=3D"monospace, mono=
space">std::partition</font>!</div><div><a href=3D"http://en.cppreference.c=
om/w/cpp/algorithm/partition" target=3D"_blank">http://en.cppreference.com/=
w/cpp/algorithm/partition<br></a></div><div><br></div><div>Adding overloads=
 of <font face=3D"monospace, monospace">remove</font>=C2=A0and=C2=A0<font f=
ace=3D"monospace, monospace">partition</font>=C2=A0that take specific itera=
tors might be a separate task worthy of a proposal.<br></div><div><a href=
=3D"http://en.cppreference.com/w/cpp/algorithm/remove" target=3D"_blank">ht=
tp://en.cppreference.com/w/cpp/algorithm/remove</a><br></div><div>It&#39;s =
not hard to wrap an iterator in a Predicate, but it&#39;s a bit annoying an=
d fiddly, and changes the complexity of the algorithm from O(1) to O(N) bec=
ause now you have to touch all the items in the list to compare them with y=
our original iterator.</div><div><br></div><div><font face=3D"monospace, mo=
nospace">auto it =3D v.find(...);</font></div><div><font face=3D"monospace,=
 monospace"><br></font></div><div><font face=3D"monospace, monospace">v.era=
se(std::partition(v.begin(), v.end(), it), v.end());</font></div><div><font=
 face=3D"monospace, monospace">=C2=A0=C2=A0// O(1), could be proposed for s=
tandardization</font></div><div><font face=3D"monospace, monospace"><br></f=
ont></div><div><font face=3D"monospace, monospace">v.erase(std::partition(v=
..begin(), v.end(), [&amp;](auto&amp; elt) { return &amp;elt =3D=3D &amp;*it=
; });</font></div><div><font face=3D"monospace, monospace">=C2=A0=C2=A0// O=
(N), already standardized</font></div></div></div></div></blockquote><div><=
br></div></span><div>Of course I meant=C2=A0<span style=3D"font-family:mono=
space,monospace">return &amp;elt <b>!=3D</b> &amp;*it</span>=C2=A0on the li=
ne above.=C2=A0 Bother.</div><span class=3D"HOEnZb"><font color=3D"#888888"=
><div><br></div><div>=E2=80=93Arthur</div></font></span></div></div></div><=
div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01494654b11658051a8712b8--

.

--089e0122a222ddf72f051a8728b5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
> first++ =3D std::move(last);


That was meant to be *first++ =3D std::move(*last);

On Fri, Jul 10, 2015 at 10:31 AM, Brent Friedman <fourthgeek@gmail.com>
wrote:

> The proposed unstable_remove algorithm is *precisely* std::partition!
>
>
> Partition isn't exactly the same as unstable_remove, but they are ever so
> almost the same.
>
> In partition, we swap the elements. This leaves objects on both sides of
> the partition point in a well-defined state.
>
> unordered_remove would move-assign elements, leaving objects on the right
> side of the partition point in a valid but unspecified state as per the
> MoveAssignable post condition and as per the remove algorithms.
>
> In the implementation of partition on cppreference, instead of
> std::iter_swap(first++, last); it would be first++ =3D std::move(last);
>
> For many types, move-assignment may be implemented in terms of swap so th=
e
> difference is negligible. However for something like int, swap does more
> work than is necessary.
>
> On Fri, Jul 10, 2015 at 9:50 AM, Arthur O'Dwyer <arthur.j.odwyer@gmail.co=
m
> > wrote:
>
>> On Fri, Jul 10, 2015 at 5:33 AM, Arthur O'Dwyer <
>> arthur.j.odwyer@gmail.com> wrote:
>>
>>>
>>> *Wait a minute!*
>>>
>>> The proposed unstable_remove algorithm is *precisely* std::partition!
>>> http://en.cppreference.com/w/cpp/algorithm/partition
>>>
>>> Adding overloads of remove and partition that take specific iterators
>>> might be a separate task worthy of a proposal.
>>> http://en.cppreference.com/w/cpp/algorithm/remove
>>> It's not hard to wrap an iterator in a Predicate, but it's a bit
>>> annoying and fiddly, and changes the complexity of the algorithm from O=
(1)
>>> to O(N) because now you have to touch all the items in the list to comp=
are
>>> them with your original iterator.
>>>
>>> auto it =3D v.find(...);
>>>
>>> v.erase(std::partition(v.begin(), v.end(), it), v.end());
>>>   // O(1), could be proposed for standardization
>>>
>>> v.erase(std::partition(v.begin(), v.end(), [&](auto& elt) { return &elt
>>> =3D=3D &*it; });
>>>   // O(N), already standardized
>>>
>>
>> Of course I meant return &elt *!=3D* &*it on the line above.  Bother.
>>
>> =E2=80=93Arthur
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e0122a222ddf72f051a8728b5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span style=3D"font-size:12.8000001907349=
px">first++ =3D std::move(last);</span></blockquote><div>=C2=A0</div>That w=
as meant to be *first++ =3D std::move(*last);</div><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Fri, Jul 10, 2015 at 10:31 AM, Brent F=
riedman <span dir=3D"ltr">&lt;<a href=3D"mailto:fourthgeek@gmail.com" targe=
t=3D"_blank">fourthgeek@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><span class=3D""><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span sty=
le=3D"font-size:12.8000001907349px">The proposed unstable_remove algorithm =
is=C2=A0</span><i style=3D"font-size:12.8000001907349px">precisely</i><span=
 style=3D"font-size:12.8000001907349px">=C2=A0</span><font face=3D"monospac=
e, monospace" style=3D"font-size:12.8000001907349px">std::partition</font><=
span style=3D"font-size:12.8000001907349px">!</span></blockquote><div>=C2=
=A0</div></span>Partition isn&#39;t exactly the same as unstable_remove, bu=
t they are ever so almost the same.<div><br></div><div>In partition, we swa=
p the elements. This leaves objects on both sides of the partition point in=
 a well-defined state.</div><div><br></div><div>unordered_remove would move=
-assign elements, leaving objects on the right side of the partition point =
in a valid but unspecified state as per the MoveAssignable post condition a=
nd as per the remove algorithms.</div><div><br></div><div>In the implementa=
tion of partition on cppreference, instead of std::iter_swap(first++, last)=
; it would be first++ =3D std::move(last);</div><div><br></div><div>For man=
y types, move-assignment may be implemented in terms of swap so the differe=
nce is negligible. However for something like int, swap does more work than=
 is necessary.</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jul 10, 2015 at 9:=
50 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.j.=
odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Fri, J=
ul 10, 2015 at 5:33 AM, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D=
"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.=
com</a>&gt;</span> wrote:<br></span><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><span><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra"><div class=3D"gmail_quote"><span><div><br></div></span><div><i><b>=
Wait a minute!</b></i></div><div><br></div><div>The proposed unstable_remov=
e algorithm is <i>precisely</i> <font face=3D"monospace, monospace">std::pa=
rtition</font>!</div><div><a href=3D"http://en.cppreference.com/w/cpp/algor=
ithm/partition" target=3D"_blank">http://en.cppreference.com/w/cpp/algorith=
m/partition<br></a></div><div><br></div><div>Adding overloads of <font face=
=3D"monospace, monospace">remove</font>=C2=A0and=C2=A0<font face=3D"monospa=
ce, monospace">partition</font>=C2=A0that take specific iterators might be =
a separate task worthy of a proposal.<br></div><div><a href=3D"http://en.cp=
preference.com/w/cpp/algorithm/remove" target=3D"_blank">http://en.cpprefer=
ence.com/w/cpp/algorithm/remove</a><br></div><div>It&#39;s not hard to wrap=
 an iterator in a Predicate, but it&#39;s a bit annoying and fiddly, and ch=
anges the complexity of the algorithm from O(1) to O(N) because now you hav=
e to touch all the items in the list to compare them with your original ite=
rator.</div><div><br></div><div><font face=3D"monospace, monospace">auto it=
 =3D v.find(...);</font></div><div><font face=3D"monospace, monospace"><br>=
</font></div><div><font face=3D"monospace, monospace">v.erase(std::partitio=
n(v.begin(), v.end(), it), v.end());</font></div><div><font face=3D"monospa=
ce, monospace">=C2=A0=C2=A0// O(1), could be proposed for standardization</=
font></div><div><font face=3D"monospace, monospace"><br></font></div><div><=
font face=3D"monospace, monospace">v.erase(std::partition(v.begin(), v.end(=
), [&amp;](auto&amp; elt) { return &amp;elt =3D=3D &amp;*it; });</font></di=
v><div><font face=3D"monospace, monospace">=C2=A0=C2=A0// O(N), already sta=
ndardized</font></div></div></div></div></blockquote><div><br></div></span>=
<div>Of course I meant=C2=A0<span style=3D"font-family:monospace,monospace"=
>return &amp;elt <b>!=3D</b> &amp;*it</span>=C2=A0on the line above.=C2=A0 =
Bother.</div><span><font color=3D"#888888"><div><br></div><div>=E2=80=93Art=
hur</div></font></span></div></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122a222ddf72f051a8728b5--

.

--bcaec53d5b51ea3499051a87f068
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10 July 2015 at 04:17, Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com> wrot=
e:

> A specialization is necessary for std::list which simply calls
> a_list.erase(an_iterator).
>

Could you give a motivating example for using this with list?

Card dealing (aka pick w/o replacement) requires picking a random element
first.  That doesn't seem to make any sense for std::list, since it doesn't
have random access iterators.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--bcaec53d5b51ea3499051a87f068
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 10 July 2015 at 04:17, Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a href=
=3D"mailto:aymeric.pelle@gmail.com" target=3D"_blank">aymeric.pelle@gmail.c=
om</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>A specializ=
ation is necessary for std::list which simply calls <span style=3D"font-fam=
ily:courier new,monospace">a_list.erase(an_iterator)</span>.<br></div><div>=
</div></blockquote></div><br>Could you give a motivating example for using =
this with list?</div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">Card dealing (aka pick w/o replacement) requires picking a random=
 element first.=C2=A0 That doesn&#39;t seem to make any sense for std::list=
, since it doesn&#39;t have random access iterators.<br>-- <br><div class=
=3D"gmail_signature">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a =
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord=
..com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec53d5b51ea3499051a87f068--

.

--089e0158b5e47522ad051a880ea2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think he meant that since the =C2=ABbasic=C2=BB implementation of this al=
gorithm
would be a pessimization for std::list, providing a specialized version
that defers to list's specific services might be a good idea.

In practice, as far as I know, this unstable_erase() trick, nice as it is,
is really more associated with vector operations, but if we can avoid
making code run slower due to a change in container...

2015-07-10 12:33 GMT-04:00 Nevin Liber <nevin@eviloverlord.com>:

>
> On 10 July 2015 at 04:17, Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com> wr=
ote:
>
>> A specialization is necessary for std::list which simply calls
>> a_list.erase(an_iterator).
>>
>
> Could you give a motivating example for using this with list?
>
> Card dealing (aka pick w/o replacement) requires picking a random element
> first.  That doesn't seem to make any sense for std::list, since it doesn=
't
> have random access iterators.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e0158b5e47522ad051a880ea2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I think he meant that since the =C2=ABbasic=C2=BB imp=
lementation of this algorithm would be a pessimization for std::list, provi=
ding a specialized version that defers to list&#39;s specific services migh=
t be a good idea.<br><br></div>In practice, as far as I know, this unstable=
_erase() trick, nice as it is, is really more associated with vector operat=
ions, but if we can avoid making code run slower due to a change in contain=
er...<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">20=
15-07-10 12:33 GMT-04:00 Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;<=
/span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><span class=3D""><br><div class=3D"gmail_quote">On 10 July 2015 =
at 04:17, Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a href=3D"mailto:aymeri=
c.pelle@gmail.com" target=3D"_blank">aymeric.pelle@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div>A specialization is necessar=
y for std::list which simply calls <span style=3D"font-family:courier new,m=
onospace">a_list.erase(an_iterator)</span>.<br></div><div></div></blockquot=
e></div><br></span>Could you give a motivating example for using this with =
list?</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">=
Card dealing (aka pick w/o replacement) requires picking a random element f=
irst.=C2=A0 That doesn&#39;t seem to make any sense for std::list, since it=
 doesn&#39;t have random access iterators.<span class=3D""><br>-- <br><div>=
=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@=
eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a=
 href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank"=
>(847) 691-1404</a></div>
</span></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0158b5e47522ad051a880ea2--

.

------=_Part_3054_202835853.1436650523013
Content-Type: multipart/alternative;
 boundary="----=_Part_3055_1831354650.1436650523014"

------=_Part_3055_1831354650.1436650523014
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Le vendredi 10 juillet 2015 18:42:26 UTC+2, Patrice Roy a =C3=A9crit :
>
> I think he meant that since the =C2=ABbasic=C2=BB implementation of this =
algorithm=20
> would be a pessimization for std::list, providing a specialized version=
=20
> that defers to list's specific services might be a good idea.
>

Exactly. :)
=20

> In practice, as far as I know, this unstable_erase() trick, nice as it is=
,=20
> is really more associated with vector operations,=20
>

I agree that unstable_erase() is more associated with container providing=
=20
random access, and vector particularly.
It is not really expected to be used with list.
=20

> but if we can avoid making code run slower due to a change in container..=
..
>

John Bytheway suggested unstable_erase(), as a function, could work with=20
SequenceContainer.
That's why I considered the pessimization for std::list that other people=
=20
pointed out.
So, if we limit unstable_erase() only to containers providing random=20
access, I won't be against.
(It would solve the hairy detail with the partial specialization that=20
Arthur O'Dwyer pointed out. (Is it really troublesome?))

After, ...

>  2015-07-10 12:33 GMT-04:00 Nevin Liber <ne...@eviloverlord.com=20
> <javascript:>>:
>
>>
>> Could you give a motivating example for using this with list?
>>
>
You can imagine such an algorithm :

template <class Container>
void my_template_algorithm (Container& c)
{
  for (auto iter =3D c.begin(); iter!=3D c.end(); )
  {
    update(*iter);
    if (is_invalid(*iter))
      unstable_erase(c, iter);
    else
    {
      update_2(*iter);
      ++iter;
    }
  }
}

(Yes, it isn't really a concrete example.)
With such an example, you can imagine a user calling=20
my_template_algorithm() with a std::list<T> as parameter.
Do this case or similar ones happen enough to consider unstable_erase() be=
=20
available with std::list-like containers?
I don't think so, but maybe I'm wrong..=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_3055_1831354650.1436650523014
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>Le vendredi 10 juillet 2015 18:42:26 UTC+2, Patrice Ro=
y a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>I think he meant that since the =C2=ABbasic=C2=BB implementat=
ion of this algorithm would be a pessimization for std::list, providing a s=
pecialized version that defers to list&#39;s specific services might be a g=
ood idea.<br></div></div></blockquote><div><br>Exactly. :)<br>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">In practice, a=
s far as I know, this unstable_erase() trick, nice as it is, is really more=
 associated with vector operations, </div></blockquote><div><br>I agree tha=
t unstable_erase() is more associated with container providing random acces=
s, and vector particularly.<br>It is not really expected to be used with li=
st.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>but if=
 we can avoid making code run slower due to a change in container...<br></d=
iv></blockquote><div><br>John Bytheway suggested unstable_erase(), as a fun=
ction, could work with SequenceContainer.<br>That&#39;s why I considered th=
e pessimization for std::list that other people pointed out.<br>So, if we l=
imit unstable_erase() only to containers providing random access, I won&#39=
;t be against.<br>(It would solve the hairy detail with the partial special=
ization that Arthur O&#39;Dwyer pointed out. (Is it really troublesome?))<b=
r><br>After, ...<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 class=3D"gmail_quote">=C2=A02015-07-10 12:33 GMT-04:00 Nevin Liber <span d=
ir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"th=
is.href=3D&#39;javascript:&#39;;return true;">ne...@eviloverlord.com</a>&gt=
;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span><br=
></span>Could you give a motivating example for using this with list?</div>=
</div></blockquote></div></blockquote><br>You can imagine such an algorithm=
 :<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 25=
0, 250); border-color: rgb(187, 187, 187); border-style: solid; border-widt=
h: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"s=
ubprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">te=
mplate</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">class</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Container</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> my_template_algorithm </span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Container</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">for</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> iter </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> c</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">.</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">begin</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i=
ter</span><span style=3D"color: #660;" class=3D"styled-by-prettify">!=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> c</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">end</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br>=C2=A0 =C2=A0 update</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(*</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">iter</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">is_invalid</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">(*</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">iter</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">))</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 unstable_erase</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">c</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> iter</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">else</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 update_2</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(*</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">iter</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">++</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">iter</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span></div></code></div><span style=3D"font-family: courier new,mono=
space;"><br></span>(Yes, it isn&#39;t really a concrete example.)<br>With s=
uch an example, you can imagine a user calling my_template_algorithm() with=
 a std::list&lt;T&gt; as parameter.<br>Do this case or similar ones happen =
enough to consider unstable_erase() be available with std::list-like contai=
ners?<br>I don&#39;t think so, but maybe I&#39;m wrong.. <br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3055_1831354650.1436650523014--
------=_Part_3054_202835853.1436650523013--

.

------=_Part_2061_363906506.1436665209624
Content-Type: multipart/alternative;
 boundary="----=_Part_2062_374022618.1436665209625"

------=_Part_2062_374022618.1436665209625
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Le vendredi 10 juillet 2015 14:33:56 UTC+2, Arthur O'Dwyer a =C3=A9crit :
>
> On Fri, Jul 10, 2015 at 2:17 AM, Aymeric Pell=C3=A9 <aymeri...@gmail.com=
=20
> <javascript:>> wrote:
>
>> It sounds like this function could be added to <algorithm> as follows...
>>>
>>> namespace std {
>>> template<typename C, typename It>
>>> void unstable_erase(C& container, const It& elt) {
>>>     *elt =3D std::move(container.back());  // OOPS
>>>     container.pop_back();
>>> }
>>> } // namespace std
>>>
>>> ...except that the line marked "OOPS" will invoke undefined behavior in=
=20
>>> the case that iterator =3D=3D container.end()-1,=20
>>>
>>
>> There is no problem with this line.
>> When you implement operator=3D (const T& t) for a class, you have to=20
>> manage the case where &t =3D=3D this.
>> It is the same with r-values, you have to manage this case anyway. You=
=20
>> can imagine an algorithm where this can happen.
>>
>
> I tend to agree with your opinion in general...
> =20
>
>> Standard library types manage this case.
>>
>
> ...Sadly, they *explicitly* do not.  x =3D std::move(x) is *always*=20
> undefined behavior, when x is a standard library type.
> See my C++Now talk, whenever it hits YouTube; or any of the myriad=20
> questions on the subject on StackOverflow.
>
(Thank you for the precision. Indeed, this is sad.)
=20

> Let's not derail this thread with the details.
>
(Ok)
=20

> and as David pointed out, it will be pessimal in the case that C is=20
>>> std::list (so it needs a partial specialization, which means some=20
>>> additional hairiness in the implementation).
>>>
>>
>> A specialization is necessary for std::list which simply calls=20
>> a_list.erase(an_iterator).
>>
>
> Right; and this has to be a *partial* specialization for std::list<T>,=20
> which means you'll have to implement it using a helper class, because=20
> function templates can't be partially specialized. That's the hairy detai=
l=20
> to which I referred.
> However, unless std::remove is already specialized for std::list<T>, I=20
> don't think unstable_remove should be specialized in that way; the=20
> asymmetry would be more confusing than helpful, and it would eliminate th=
e=20
> possibility of using unstable_remove-without-the-subsequent-erase as a=20
> partitioning algorithm...
>
> *Wait a minute!*
>
> The proposed unstable_remove algorithm is *precisely* std::partition!
> http://en.cppreference.com/w/cpp/algorithm/partition
>
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp=
%2Falgorithm%2Fpartition&sa=3DD&sntz=3D1&usg=3DAFQjCNHbOoMtW4lQ2cn7H4KMpFdT=
7koeeg>
>
> Adding overloads of remove and partition that take specific iterators=20
> might be a separate task worthy of a proposal.
> http://en.cppreference.com/w/cpp/algorithm/remove=20
> <http://www.google.com/url?q=3Dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp=
%2Falgorithm%2Fremove&sa=3DD&sntz=3D1&usg=3DAFQjCNHUrOXmAwYSn_-TUoBXRGz8rjh=
jxA>
> It's not hard to wrap an iterator in a Predicate, but it's a bit annoying=
=20
> and fiddly, and changes the complexity of the algorithm from O(1) to O(N)=
=20
> because now you have to touch all the items in the list to compare them=
=20
> with your original iterator.
>
> auto it =3D v.find(...);
>
> v.erase(std::partition(v.begin(), v.end(), it), v.end());
>   // O(1), could be proposed for standardization
>
> v.erase(std::partition(v.begin(), v.end(), [&](auto& elt) { return &elt =
=3D=3D=20
> &*it; });
>   // O(N), already standardized
>
> =E2=80=93Arthur
>

unstable_remove() could be used as a partition function, but I am not sure=
=20
I'd encourage one to name it partition.
After all, except for using it to do an unstable_erase, I don't see another=
=20
context where someone would use it.
Is it pertinent to name a function partition when one of the two part of=20
the generated sequence is always empty?
(Should we discuss this subject in another proposal? I agree it might be=20
worthy to define remove specialization for std::list<T>, if it isn't=20
already the case.)

I would like to sum up the use case and the solutions:
We have a SequenceContainer *c* (which provides random access?).
The order of elements doesn't matter in our case.
We want to remove an element pointed by an iterator *it* from *c* with O(1)=
..

The solution (A) to replace:
*it =3D std::move(c.back());
c.pop_back();
Providing a standard solution would help spread this useful trick to people=
=20
who don't know it.

A solution with std::unstable_remove() (B):
c.erase(std::unstable_remove(c.begin(), c.end(), it));

A solution with std::unstable_erase() (C):
std::unstable_erase(c, it);

I maintain that the solution (C) is necessary.
It wouldn't be superfluous since STL has proposed uniform container erasure=
=20
interface, as TONGARI J said.

If the solution (C) is retained, would unstable_remove() be still pertinent=
?

Is the solution (B) less efficient than the solution (A) due to the loop=20
test in the erase() function?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_2062_374022618.1436665209625
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><br>Le vendredi 10 juillet 2015 14:33:56 UTC+2, Arthur O&#39;Dwyer a =
=C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Fri, Jul 10, 2015 at 2:17 AM, Aymeric Pell=C3=A9 <span dir=3D"ltr">&=
lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">aymeri...@gmail.com</a>&gt;</span> wrot=
e:<br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><span><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr"><div>It sounds like this function could be added to &lt=
;algorithm&gt; as follows...</div><div><br></div><div><font face=3D"courier=
 new, monospace">namespace std {</font></div><div><font face=3D"courier new=
, monospace">template&lt;typename C, typename It&gt;</font></div><font face=
=3D"courier new, monospace">void unstable_erase(C&amp; container, const It&=
amp; elt) {</font><div><font face=3D"courier new, monospace">=C2=A0 =C2=A0 =
*elt =3D std::move(container.back()); =C2=A0// OOPS</font></div><div><font =
face=3D"courier new, monospace">=C2=A0 =C2=A0 container.pop_back();</font><=
/div><div><font face=3D"courier new, monospace">}<br></font><div><font face=
=3D"courier new, monospace">} // namespace std</font><div><br></div><div>..=
..except that the line marked &quot;OOPS&quot; will invoke undefined behavio=
r in the case that <font face=3D"courier new, monospace">iterator =3D=3D co=
ntainer.end()-1</font>, </div></div></div></div></blockquote></span><div><b=
r>There is no problem with this line.<br>When you implement <span style=3D"=
font-family:&#39;courier new&#39;,monospace">operator=3D</span> <span style=
=3D"font-family:&#39;courier new&#39;,monospace">(const T&amp; t)</span> fo=
r a class, you have to manage the case where &amp;t =3D=3D this.<br>It is t=
he same with r-values, you have to manage this case anyway. You can imagine=
 an algorithm where this can happen.<br></div></blockquote><div><br></div><=
div>I tend to agree with your opinion in general...</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div>Standard library types manage this case.<br></div></bl=
ockquote><div><br></div><div>...Sadly, they <b>explicitly</b> do not. =C2=
=A0x =3D std::move(x) is <b>always</b> undefined behavior, when x is a stan=
dard library type.</div><div>See my C++Now talk, whenever it hits YouTube; =
or any of the myriad questions on the subject on StackOverflow.</div></div>=
</div></div></blockquote><div>(Thank you for the precision. Indeed, this is=
 sad.)<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div>Let&#39;s not derail this thr=
ead with the details.</div></div></div></div></blockquote><div>(Ok)<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,20=
4);border-left-style:solid;padding-left:1ex"><div></div><span><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><div dir=3D"ltr"><div><div><div>and as David pointed out, it will be pe=
ssimal in the case that C is std::list (so it needs a partial specializatio=
n, which means some additional hairiness in the implementation).</div></div=
></div></div></blockquote></span><div><br>A specialization is necessary for=
 std::list which simply calls <span style=3D"font-family:&#39;courier new&#=
39;,monospace">a_list.erase(an_iterator)</span>.<br></div></blockquote><div=
><br></div><div>Right; and this has to be a <b>partial</b> specialization f=
or std::list&lt;T&gt;, which means you&#39;ll have to implement it using a =
helper class, because function templates can&#39;t be partially specialized=
.. That&#39;s the hairy detail to which I referred.</div><div>However, unles=
s <font face=3D"monospace, monospace">std::remove</font> is already special=
ized for <font face=3D"monospace, monospace">std::list&lt;T&gt;</font>, I d=
on&#39;t think <font face=3D"monospace, monospace">unstable_remove</font> s=
hould be specialized in that way; the asymmetry would be more confusing tha=
n helpful, and it would eliminate the possibility of using <font face=3D"mo=
nospace, monospace">unstable_remove</font>-without-the-subsequent-<font fac=
e=3D"monospace, monospace">erase</font> as a partitioning algorithm...</div=
><div><br></div><div><i><b>Wait a minute!</b></i></div><div><br></div><div>=
The proposed unstable_remove algorithm is <i>precisely</i> <font face=3D"mo=
nospace, monospace">std::partition</font>!</div><div><a href=3D"http://www.=
google.com/url?q=3Dhttp%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Falgorithm%2=
Fpartition&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNHbOoMtW4lQ2cn7H4KMpFdT7k=
oeeg" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Fal=
gorithm%2Fpartition\46sa\75D\46sntz\0751\46usg\75AFQjCNHbOoMtW4lQ2cn7H4KMpF=
dT7koeeg&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.google.c=
om/url?q\75http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Falgorithm%2Fpartiti=
on\46sa\75D\46sntz\0751\46usg\75AFQjCNHbOoMtW4lQ2cn7H4KMpFdT7koeeg&#39;;ret=
urn true;">http://en.cppreference.com/w/cpp/algorithm/partition<br></a></di=
v><div><br></div><div>Adding overloads of <font face=3D"monospace, monospac=
e">remove</font>=C2=A0and=C2=A0<font face=3D"monospace, monospace">partitio=
n</font>=C2=A0that take specific iterators might be a separate task worthy =
of a proposal.<br></div><div><a href=3D"http://www.google.com/url?q=3Dhttp%=
3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Falgorithm%2Fremove&amp;sa=3DD&amp;s=
ntz=3D1&amp;usg=3DAFQjCNHUrOXmAwYSn_-TUoBXRGz8rjhjxA" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\7=
5http%3A%2F%2Fen.cppreference.com%2Fw%2Fcpp%2Falgorithm%2Fremove\46sa\75D\4=
6sntz\0751\46usg\75AFQjCNHUrOXmAwYSn_-TUoBXRGz8rjhjxA&#39;;return true;" on=
click=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fen.cpp=
reference.com%2Fw%2Fcpp%2Falgorithm%2Fremove\46sa\75D\46sntz\0751\46usg\75A=
FQjCNHUrOXmAwYSn_-TUoBXRGz8rjhjxA&#39;;return true;">http://en.cppreference=
..com/w/cpp/algorithm/remove</a><br></div><div>It&#39;s not hard to wrap an =
iterator in a Predicate, but it&#39;s a bit annoying and fiddly, and change=
s the complexity of the algorithm from O(1) to O(N) because now you have to=
 touch all the items in the list to compare them with your original iterato=
r.</div><div><br></div><div><font face=3D"monospace, monospace">auto it =3D=
 v.find(...);</font></div><div><font face=3D"monospace, monospace"><br></fo=
nt></div><div><font face=3D"monospace, monospace">v.erase(std::partition(v.=
begin(), v.end(), it), v.end());</font></div><div><font face=3D"monospace, =
monospace">=C2=A0=C2=A0// O(1), could be proposed for standardization</font=
></div><div><font face=3D"monospace, monospace"><br></font></div><div><font=
 face=3D"monospace, monospace">v.erase(std::partition(v.begin(), v.end(), [=
&amp;](auto&amp; elt) { return &amp;elt =3D=3D &amp;*it; });</font></div><d=
iv><font face=3D"monospace, monospace">=C2=A0=C2=A0// O(N), already standar=
dized</font></div><div><br></div><div>=E2=80=93Arthur</div></div></div></di=
v></blockquote><div><br>unstable_remove() could be used as a partition func=
tion, but I am not sure I&#39;d encourage one to name it <span style=3D"fon=
t-family: courier new,monospace;">partition</span>.<br>After all, except fo=
r using it to do an <span style=3D"font-family: courier new,monospace;">uns=
table_erase</span>, I don&#39;t see another context where someone would use=
 it.<br>Is it pertinent to name a function partition when one of the two pa=
rt of the generated sequence is always empty?<br>(Should we discuss this su=
bject in another proposal? I agree it might be worthy to define <font face=
=3D"monospace, monospace"><span style=3D"font-family: courier new,monospace=
;">remove</span> </font><span style=3D"font-family: arial,sans-serif;">spec=
ialization </span><font face=3D"monospace, monospace"><span style=3D"font-f=
amily: arial,sans-serif;">for </span><font face=3D"monospace, monospace">st=
d::list&lt;T&gt;</font><span style=3D"font-family: arial,sans-serif;">, if =
it isn&#39;t already the case.</span></font>)<br><br>I would like to sum up=
 the use case and the solutions:<br>We have a SequenceContainer <i>c</i> (w=
hich provides random access?).<br>The order of elements doesn&#39;t matter =
in our case.<br>We want to remove an element pointed by an iterator <i>it</=
i> from <i>c</i> with O(1).<br><br>The solution (A) to replace:<br><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">it </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">back</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">());</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>c</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">pop_back</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div>Providing a standar=
d solution would help spread this useful trick to people who don&#39;t know=
 it.<br><br>A solution with std::unstable_remove() (B):<br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">c</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">erase</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
unstable_remove</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> c</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">end</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(),</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> it</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">));</span></div></code></div><br>A solution with std::unstable_erase() (=
C):<br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, =
250); border-color: rgb(187, 187, 187); border-style: solid; border-width: =
1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">std</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">unstable_erase</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">c</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> it</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span></div></code></div><br>I maintain that th=
e solution (C) is necessary.<br>It wouldn&#39;t be superfluous since STL ha=
s proposed uniform container erasure interface, as TONGARI J said.<br><br>I=
f the solution (C) is retained, would <span style=3D"font-family: courier n=
ew,monospace;">unstable_remove()</span> be still pertinent?<br><br>Is the s=
olution (B) less efficient than the solution (A) due to the loop test in th=
e <span style=3D"font-family: courier new,monospace;">erase()</span> functi=
on?<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2062_374022618.1436665209625--
------=_Part_2061_363906506.1436665209624--

.

------=_Part_4019_1013467780.1436686073007
Content-Type: multipart/alternative;
 boundary="----=_Part_4020_29216945.1436686073008"

------=_Part_4020_29216945.1436686073008
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've always just called it swap-and-pop. (perhaps a misnomer, since one=20
wouldn't actually _swap_... it's more like move-and-pop, I guess.)

Literally just used it like two hours ago, too, and I'm pretty sure I'm=20
about to use it again in a debug draw optimization refactor... and there's=
=20
no card shuffling in sight. :p

Super useful for cache-friendly data stores (it's O(1)=20
defragmentation/compaction). Game objects/components, particle engines,=20
etc. Sometimes needs to be paired with an indirection table (e.g.=20
http://bitsquid.blogspot.com/2011/09/managing-decoupling-part-4-id-lookup.h=
tml=20
).

That said, yeah, I'm not sure how useful it would be to standardize. It's=
=20
so small and simple of a micro-algorithm that I can't ever imagine wanting=
=20
to include <algorithm> just to condense two or three lines into one. Also,=
=20
in my experience it ends up being used in the kinds of algorithms and data=
=20
structures where paying the cost for umpteen layers of abstraction with a=
=20
standard container and the algorithm library is totally not worth the lazy=
=20
factor. :p

On Wednesday, July 8, 2015 at 12:29:09 PM UTC-7, Patrice Roy wrote:
>
> I know many in the game industry use a variant of this, usually called=20
> erase_with_last_swap(), as O(1) removal of any element is sometimes very=
=20
> useful. It's always seemed to me like a nice trick to know more than a=20
> candidate for standardization; maybe I'm wrong. It does not smell like a=
=20
> candidate to become a member function to me, though.
>
> 2015-07-08 10:55 GMT-04:00 Nevin Liber <ne...@eviloverlord.com=20
> <javascript:>>:
>
>> On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeri...@gmail.com <javasc=
ript:>
>> > wrote:
>>
>>> I exposed this idea here to see if other people (who don't need to=20
>>> converse order in vector and use erase()) are interested or concerned b=
y=20
>>> this case.
>>>
>>
>> You've provided no motivation why people would want to do such a thing.
>>
>> The only scenario I can think of is dealing cards, and that just doesn't=
=20
>> come up often enough to be worth standardizing.
>> --=20
>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com <javascript:>>  (847)=
=20
>> 691-1404
>> =20
>> --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_4020_29216945.1436686073008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve always just called it swap-and-pop. (perhaps a mi=
snomer, since one wouldn&#39;t actually _swap_... it&#39;s more like move-a=
nd-pop, I guess.)<div><br></div><div>Literally just used it like two hours =
ago, too, and I&#39;m pretty sure I&#39;m about to use it again in a debug =
draw optimization refactor... and there&#39;s no card shuffling in sight. :=
p</div><div><br></div><div>Super useful for cache-friendly data stores (it&=
#39;s O(1) defragmentation/compaction). Game objects/components, particle e=
ngines, etc. Sometimes needs to be paired with an indirection table (e.g. h=
ttp://bitsquid.blogspot.com/2011/09/managing-decoupling-part-4-id-lookup.ht=
ml ).</div><div><br></div><div>That said, yeah, I&#39;m not sure how useful=
 it would be to standardize. It&#39;s so small and simple of a micro-algori=
thm that I can&#39;t ever imagine wanting to include &lt;algorithm&gt; just=
 to condense two or three lines into one. Also, in my experience it ends up=
 being used in the kinds of algorithms and data structures where paying the=
 cost for umpteen layers of abstraction with a standard container and the a=
lgorithm library is totally not worth the lazy factor. :p</div><div><br></d=
iv><div>On Wednesday, July 8, 2015 at 12:29:09 PM UTC-7, Patrice Roy wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I know m=
any in the game industry use a variant of this, usually called erase_with_l=
ast_swap(), as O(1) removal of any element is sometimes very useful. It&#39=
;s always seemed to me like a nice trick to know more than a candidate for =
standardization; maybe I&#39;m wrong. It does not smell like a candidate to=
 become a member function to me, though.<code><br></code></div></div><div><=
br><div class=3D"gmail_quote">2015-07-08 10:55 GMT-04:00 Nevin Liber <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">ne...@eviloverlord.com</a>&g=
t;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><span>On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">aymeri...@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I exp=
osed this idea here to see if other people (who don&#39;t need to converse =
order in vector and use erase()) are interested or concerned by this case.<=
br></div></div></blockquote><div><br></div></span><div>You&#39;ve provided =
no motivation why people would want to do such a thing.</div><div><br></div=
><div>The only scenario I can think of is dealing cards, and that just does=
n&#39;t come up often enough to be worth standardizing.</div></div><span><f=
ont color=3D"#888888">-- <br><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &=
lt;mailto:<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;">ne...@eviloverlord.com</a>&gt;=C2=
=A0 <a value=3D"+18476911404">(847) 691-1404</a></div>
</font></span></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4020_29216945.1436686073008--
------=_Part_4019_1013467780.1436686073007--

.

--001a1134946cb8903b051aae8342
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

It is simple (although it's also simple to mess-up :) ). I doubt you'd be
=C2=ABpaying the cost for umpteen layers of abstraction with a standard
container and the algorithm library=C2=BB with somtehing so easy to inline,=
 that
being said.

2015-07-12 3:27 GMT-04:00 Sean Middleditch <sean.middleditch@gmail.com>:

> I've always just called it swap-and-pop. (perhaps a misnomer, since one
> wouldn't actually _swap_... it's more like move-and-pop, I guess.)
>
> Literally just used it like two hours ago, too, and I'm pretty sure I'm
> about to use it again in a debug draw optimization refactor... and there'=
s
> no card shuffling in sight. :p
>
> Super useful for cache-friendly data stores (it's O(1)
> defragmentation/compaction). Game objects/components, particle engines,
> etc. Sometimes needs to be paired with an indirection table (e.g.
> http://bitsquid.blogspot.com/2011/09/managing-decoupling-part-4-id-lookup=
..html
> ).
>
> That said, yeah, I'm not sure how useful it would be to standardize. It's
> so small and simple of a micro-algorithm that I can't ever imagine wantin=
g
> to include <algorithm> just to condense two or three lines into one. Also=
,
> in my experience it ends up being used in the kinds of algorithms and dat=
a
> structures where paying the cost for umpteen layers of abstraction with a
> standard container and the algorithm library is totally not worth the laz=
y
> factor. :p
>
> On Wednesday, July 8, 2015 at 12:29:09 PM UTC-7, Patrice Roy wrote:
>>
>> I know many in the game industry use a variant of this, usually called
>> erase_with_last_swap(), as O(1) removal of any element is sometimes very
>> useful. It's always seemed to me like a nice trick to know more than a
>> candidate for standardization; maybe I'm wrong. It does not smell like a
>> candidate to become a member function to me, though.
>>
>> 2015-07-08 10:55 GMT-04:00 Nevin Liber <ne...@eviloverlord.com>:
>>
>>> On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeri...@gmail.com> wrote=
:
>>>
>>>> I exposed this idea here to see if other people (who don't need to
>>>> converse order in vector and use erase()) are interested or concerned =
by
>>>> this case.
>>>>
>>>
>>> You've provided no motivation why people would want to do such a thing.
>>>
>>> The only scenario I can think of is dealing cards, and that just doesn'=
t
>>> come up often enough to be worth standardizing.
>>> --
>>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a1134946cb8903b051aae8342
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It is simple (although it&#39;s also simple to mess-up :) =
). I doubt you&#39;d be =C2=ABpaying the cost for umpteen layers of abstrac=
tion with a standard container and the algorithm library=C2=BB with somtehi=
ng so easy to inline, that being said.<br></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">2015-07-12 3:27 GMT-04:00 Sean Middleditch <=
span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@gmail.com" target=
=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span>:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">I&#39;ve always just called it swap-and-pop.=
 (perhaps a misnomer, since one wouldn&#39;t actually _swap_... it&#39;s mo=
re like move-and-pop, I guess.)<div><br></div><div>Literally just used it l=
ike two hours ago, too, and I&#39;m pretty sure I&#39;m about to use it aga=
in in a debug draw optimization refactor... and there&#39;s no card shuffli=
ng in sight. :p</div><div><br></div><div>Super useful for cache-friendly da=
ta stores (it&#39;s O(1) defragmentation/compaction). Game objects/componen=
ts, particle engines, etc. Sometimes needs to be paired with an indirection=
 table (e.g. <a href=3D"http://bitsquid.blogspot.com/2011/09/managing-decou=
pling-part-4-id-lookup.html" target=3D"_blank">http://bitsquid.blogspot.com=
/2011/09/managing-decoupling-part-4-id-lookup.html</a> ).</div><div><br></d=
iv><div>That said, yeah, I&#39;m not sure how useful it would be to standar=
dize. It&#39;s so small and simple of a micro-algorithm that I can&#39;t ev=
er imagine wanting to include &lt;algorithm&gt; just to condense two or thr=
ee lines into one. Also, in my experience it ends up being used in the kind=
s of algorithms and data structures where paying the cost for umpteen layer=
s of abstraction with a standard container and the algorithm library is tot=
ally not worth the lazy factor. :p</div><div><br></div><div><span class=3D"=
">On Wednesday, July 8, 2015 at 12:29:09 PM UTC-7, Patrice Roy wrote:</span=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr">=
<div>I know many in the game industry use a variant of this, usually called=
 erase_with_last_swap(), as O(1) removal of any element is sometimes very u=
seful. It&#39;s always seemed to me like a nice trick to know more than a c=
andidate for standardization; maybe I&#39;m wrong. It does not smell like a=
 candidate to become a member function to me, though.<code><br></code></div=
></div></span><div><br><div class=3D"gmail_quote">2015-07-08 10:55 GMT-04:0=
0 Nevin Liber <span dir=3D"ltr">&lt;<a rel=3D"nofollow">ne...@eviloverlord.=
com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div=
><span class=3D""><div class=3D"gmail_quote"><span>On 8 July 2015 at 09:46,=
 Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a rel=3D"nofollow">aymeri...@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr"><div>I exposed this idea here to see if other people (who don&#39;t ne=
ed to converse order in vector and use erase()) are interested or concerned=
 by this case.<br></div></div></blockquote><div><br></div></span><div>You&#=
39;ve provided no motivation why people would want to do such a thing.</div=
><div><br></div><div>The only scenario I can think of is dealing cards, and=
 that just doesn&#39;t come up often enough to be worth standardizing.</div=
></div></span><span><font color=3D"#888888">-- <br><div>=C2=A0Nevin &quot;:=
-)&quot; Liber=C2=A0 &lt;mailto:<a rel=3D"nofollow">ne...@eviloverlord.com<=
/a>&gt;=C2=A0 <a value=3D"+18476911404">(847) 691-1404</a></div>
</font></span></div></div><div><div><span class=3D"">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1134946cb8903b051aae8342--

.

------=_Part_4476_1845138937.1436722106559
Content-Type: multipart/alternative;
 boundary="----=_Part_4477_675904434.1436722106559"

------=_Part_4477_675904434.1436722106559
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Reliance on compilers optimizing out overuse of abstractions is a big no-no=
=20
in many industries. It's the difference between having a debuggable game=20
and having a debuggable slideshow.

The reason for comments like in Mike Action's keynote last CppCon ("we just=
=20
want C99") isn't because game developers hate abstraction or that they're=
=20
not useful, but because C++ imposes too high of a penalty for using=20
abstractions, up until you rely on compiler optimizations (and then pay the=
=20
cost of slower developer iteration times).

(veering off topic, sorry)

That said, I admit that not everyone (even in games) has the same levels of=
=20
perf requirements that some of us do, so having unstable_remove in the=20
stdlib isn't entirely pointless. :)

On Sunday, July 12, 2015 at 7:35:22 AM UTC-7, Patrice Roy wrote:
>
> It is simple (although it's also simple to mess-up :) ). I doubt you'd be=
=20
> =C2=ABpaying the cost for umpteen layers of abstraction with a standard=
=20
> container and the algorithm library=C2=BB with somtehing so easy to inlin=
e, that=20
> being said.
>
> 2015-07-12 3:27 GMT-04:00 Sean Middleditch <sean.mid...@gmail.com=20
> <javascript:>>:
>
>> I've always just called it swap-and-pop. (perhaps a misnomer, since one=
=20
>> wouldn't actually _swap_... it's more like move-and-pop, I guess.)
>>
>> Literally just used it like two hours ago, too, and I'm pretty sure I'm=
=20
>> about to use it again in a debug draw optimization refactor... and there=
's=20
>> no card shuffling in sight. :p
>>
>> Super useful for cache-friendly data stores (it's O(1)=20
>> defragmentation/compaction). Game objects/components, particle engines,=
=20
>> etc. Sometimes needs to be paired with an indirection table (e.g.=20
>> http://bitsquid.blogspot.com/2011/09/managing-decoupling-part-4-id-looku=
p.html=20
>> ).
>>
>> That said, yeah, I'm not sure how useful it would be to standardize. It'=
s=20
>> so small and simple of a micro-algorithm that I can't ever imagine wanti=
ng=20
>> to include <algorithm> just to condense two or three lines into one. Als=
o,=20
>> in my experience it ends up being used in the kinds of algorithms and da=
ta=20
>> structures where paying the cost for umpteen layers of abstraction with =
a=20
>> standard container and the algorithm library is totally not worth the la=
zy=20
>> factor. :p
>>
>> On Wednesday, July 8, 2015 at 12:29:09 PM UTC-7, Patrice Roy wrote:
>>>
>>> I know many in the game industry use a variant of this, usually called=
=20
>>> erase_with_last_swap(), as O(1) removal of any element is sometimes ver=
y=20
>>> useful. It's always seemed to me like a nice trick to know more than a=
=20
>>> candidate for standardization; maybe I'm wrong. It does not smell like =
a=20
>>> candidate to become a member function to me, though.
>>>
>>> 2015-07-08 10:55 GMT-04:00 Nevin Liber <ne...@eviloverlord.com>:
>>>
>>>> On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeri...@gmail.com> wrot=
e:
>>>>
>>>>> I exposed this idea here to see if other people (who don't need to=20
>>>>> converse order in vector and use erase()) are interested or concerned=
 by=20
>>>>> this case.
>>>>>
>>>>
>>>> You've provided no motivation why people would want to do such a thing=
..
>>>>
>>>> The only scenario I can think of is dealing cards, and that just=20
>>>> doesn't come up often enough to be worth standardizing.
>>>> --=20
>>>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404
>>>> =20
>>>> --=20
>>>>
>>>> ---=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org.
>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>> Visit this group at=20
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>
>>>  --=20
>>
>> ---=20
>> You received this message because you are subscribed to the Google Group=
s=20
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=20
>> email to std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_4477_675904434.1436722106559
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Reliance on compilers optimizing out overuse of abstr=
actions is a big no-no in many industries. It&#39;s the difference between =
having a debuggable game and having a debuggable slideshow.<br></div><div><=
br></div><div>The reason for comments like in Mike Action&#39;s keynote las=
t CppCon (&quot;we just want C99&quot;) isn&#39;t because game developers h=
ate abstraction or that they&#39;re not useful, but because C++ imposes too=
 high of a penalty for using abstractions, up until you rely on compiler op=
timizations (and then pay the cost of slower developer iteration times).</d=
iv><div><br></div><div><div>(veering off topic, sorry)<br></div><div><br></=
div><div>That said, I admit that not everyone (even in games) has the same =
levels of perf requirements that some of us do, so having unstable_remove i=
n the stdlib isn&#39;t entirely pointless. :)</div><div><br>On Sunday, July=
 12, 2015 at 7:35:22 AM UTC-7, Patrice Roy wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr">It is simple (although it&#39;s also si=
mple to mess-up :) ). I doubt you&#39;d be =C2=ABpaying the cost for umptee=
n layers of abstraction with a standard container and the algorithm library=
=C2=BB with somtehing so easy to inline, that being said.<br></div><div><br=
><div class=3D"gmail_quote">2015-07-12 3:27 GMT-04:00 Sean Middleditch <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow=
" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D=
"this.href=3D&#39;javascript:&#39;;return true;">sean.mid...@gmail.com</a>&=
gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I&#39;ve alw=
ays just called it swap-and-pop. (perhaps a misnomer, since one wouldn&#39;=
t actually _swap_... it&#39;s more like move-and-pop, I guess.)<div><br></d=
iv><div>Literally just used it like two hours ago, too, and I&#39;m pretty =
sure I&#39;m about to use it again in a debug draw optimization refactor...=
 and there&#39;s no card shuffling in sight. :p</div><div><br></div><div>Su=
per useful for cache-friendly data stores (it&#39;s O(1) defragmentation/co=
mpaction). Game objects/components, particle engines, etc. Sometimes needs =
to be paired with an indirection table (e.g. <a href=3D"http://bitsquid.blo=
gspot.com/2011/09/managing-decoupling-part-4-id-lookup.html" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/=
url?q\75http%3A%2F%2Fbitsquid.blogspot.com%2F2011%2F09%2Fmanaging-decouplin=
g-part-4-id-lookup.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFja8dTc7FGbHmXFb=
RFhi_Q0JwzEA&#39;;return true;" onclick=3D"this.href=3D&#39;http://www.goog=
le.com/url?q\75http%3A%2F%2Fbitsquid.blogspot.com%2F2011%2F09%2Fmanaging-de=
coupling-part-4-id-lookup.html\46sa\75D\46sntz\0751\46usg\75AFQjCNFja8dTc7F=
GbHmXFbRFhi_Q0JwzEA&#39;;return true;">http://bitsquid.blogspot.com/2011/09=
/managing-decoupling-part-4-id-lookup.html</a> ).</div><div><br></div><div>=
That said, yeah, I&#39;m not sure how useful it would be to standardize. It=
&#39;s so small and simple of a micro-algorithm that I can&#39;t ever imagi=
ne wanting to include &lt;algorithm&gt; just to condense two or three lines=
 into one. Also, in my experience it ends up being used in the kinds of alg=
orithms and data structures where paying the cost for umpteen layers of abs=
traction with a standard container and the algorithm library is totally not=
 worth the lazy factor. :p</div><div><br></div><div><span>On Wednesday, Jul=
y 8, 2015 at 12:29:09 PM UTC-7, Patrice Roy wrote:</span><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span><div dir=3D"ltr"><div>I know many in the game =
industry use a variant of this, usually called erase_with_last_swap(), as O=
(1) removal of any element is sometimes very useful. It&#39;s always seemed=
 to me like a nice trick to know more than a candidate for standardization;=
 maybe I&#39;m wrong. It does not smell like a candidate to become a member=
 function to me, though.<code><br></code></div></div></span><div><br><div c=
lass=3D"gmail_quote">2015-07-08 10:55 GMT-04:00 Nevin Liber <span dir=3D"lt=
r">&lt;<a rel=3D"nofollow">ne...@eviloverlord.com</a>&gt;</span>:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div><span><div class=3D"gmail_qu=
ote"><span>On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <span dir=3D"ltr">&l=
t;<a rel=3D"nofollow">aymeri...@gmail.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div>I exposed this idea here to se=
e if other people (who don&#39;t need to converse order in vector and use e=
rase()) are interested or concerned by this case.<br></div></div></blockquo=
te><div><br></div></span><div>You&#39;ve provided no motivation why people =
would want to do such a thing.</div><div><br></div><div>The only scenario I=
 can think of is dealing cards, and that just doesn&#39;t come up often eno=
ugh to be worth standardizing.</div></div></span><span><font color=3D"#8888=
88">-- <br><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a rel=
=3D"nofollow">ne...@eviloverlord.com</a>&gt;=C2=A0 <a value=3D"+18476911404=
">(847) 691-1404</a></div>
</font></span></div></div><div><div><span>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4477_675904434.1436722106559--
------=_Part_4476_1845138937.1436722106559--

.

On 2015-07-11 17:35, Aymeric Pell=C3=A9 wrote:
>=20
> Le vendredi 10 juillet 2015 18:42:26 UTC+2, Patrice Roy a =C3=A9crit :
>=20
>     I think he meant that since the =C2=ABbasic=C2=BB implementation of t=
his
>     algorithm would be a pessimization for std::list, providing a
>     specialized version that defers to list's specific services might be
>     a good idea.
>=20
>=20
> Exactly. :)
> =20
>=20
>     In practice, as far as I know, this unstable_erase() trick, nice as
>     it is, is really more associated with vector operations,=20
>=20
>=20
> I agree that unstable_erase() is more associated with container
> providing random access, and vector particularly.
> It is not really expected to be used with list.
> =20
>=20
>     but if we can avoid making code run slower due to a change in
>     container...
>=20
>=20
> John Bytheway suggested unstable_erase(), as a function, could work with
> SequenceContainer.
> That's why I considered the pessimization for std::list that other
> people pointed out.

For what it's worth, I was not thinking about std::list so much as other
vector-like containers (e.g. your locally developed game engine's simple
and optimized vector-like class).  Maybe std::deque and std::string
(although it would be quite odd to use it with string).  But the genius
of the STL is that standard algorithms work with non-standard (i.e. not
in the standard library) containers.

Personally I would make it valid for std::list, without a specialization
(because it's not a serious pessimization; could even be faster in some
cases due to touching hotter cache lines), but not expect anyone to use
it there.

John Bytheway

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--089e0158ba0a546e00051ab8a34f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'd be curious to see which compiler would not optimize something like
that. I was at Mike Acton's presentation and paid attention; I would have
like to see actual numbers using relatively recent compilers, to be honest,
but it's also off-topic. I understand the beliefs expressed there match the
worries still expressed today.

It might require another thread, but we might need to make some measurement
with recent compilers about things like inlining to see how realistic some
beliefs are with respect to today's technology. It would help us target our
efforts better, I think.

Cheers!

2015-07-12 13:28 GMT-04:00 Sean Middleditch <sean.middleditch@gmail.com>:

> Reliance on compilers optimizing out overuse of abstractions is a big
> no-no in many industries. It's the difference between having a debuggable
> game and having a debuggable slideshow.
>
> The reason for comments like in Mike Action's keynote last CppCon ("we
> just want C99") isn't because game developers hate abstraction or that
> they're not useful, but because C++ imposes too high of a penalty for usi=
ng
> abstractions, up until you rely on compiler optimizations (and then pay t=
he
> cost of slower developer iteration times).
>
> (veering off topic, sorry)
>
> That said, I admit that not everyone (even in games) has the same levels
> of perf requirements that some of us do, so having unstable_remove in the
> stdlib isn't entirely pointless. :)
>
> On Sunday, July 12, 2015 at 7:35:22 AM UTC-7, Patrice Roy wrote:
>>
>> It is simple (although it's also simple to mess-up :) ). I doubt you'd b=
e
>> =C2=ABpaying the cost for umpteen layers of abstraction with a standard
>> container and the algorithm library=C2=BB with somtehing so easy to inli=
ne, that
>> being said.
>>
>> 2015-07-12 3:27 GMT-04:00 Sean Middleditch <sean.mid...@gmail.com>:
>>
>>> I've always just called it swap-and-pop. (perhaps a misnomer, since one
>>> wouldn't actually _swap_... it's more like move-and-pop, I guess.)
>>>
>>> Literally just used it like two hours ago, too, and I'm pretty sure I'm
>>> about to use it again in a debug draw optimization refactor... and ther=
e's
>>> no card shuffling in sight. :p
>>>
>>> Super useful for cache-friendly data stores (it's O(1)
>>> defragmentation/compaction). Game objects/components, particle engines,
>>> etc. Sometimes needs to be paired with an indirection table (e.g.
>>> http://bitsquid.blogspot.com/2011/09/managing-decoupling-part-4-id-look=
up.html
>>> ).
>>>
>>> That said, yeah, I'm not sure how useful it would be to standardize.
>>> It's so small and simple of a micro-algorithm that I can't ever imagine
>>> wanting to include <algorithm> just to condense two or three lines into
>>> one. Also, in my experience it ends up being used in the kinds of
>>> algorithms and data structures where paying the cost for umpteen layers=
 of
>>> abstraction with a standard container and the algorithm library is tota=
lly
>>> not worth the lazy factor. :p
>>>
>>> On Wednesday, July 8, 2015 at 12:29:09 PM UTC-7, Patrice Roy wrote:
>>>>
>>>> I know many in the game industry use a variant of this, usually called
>>>> erase_with_last_swap(), as O(1) removal of any element is sometimes ve=
ry
>>>> useful. It's always seemed to me like a nice trick to know more than a
>>>> candidate for standardization; maybe I'm wrong. It does not smell like=
 a
>>>> candidate to become a member function to me, though.
>>>>
>>>> 2015-07-08 10:55 GMT-04:00 Nevin Liber <ne...@eviloverlord.com>:
>>>>
>>>>> On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <aymeri...@gmail.com> wro=
te:
>>>>>
>>>>>> I exposed this idea here to see if other people (who don't need to
>>>>>> converse order in vector and use erase()) are interested or concerne=
d by
>>>>>> this case.
>>>>>>
>>>>>
>>>>> You've provided no motivation why people would want to do such a thin=
g.
>>>>>
>>>>> The only scenario I can think of is dealing cards, and that just
>>>>> doesn't come up often enough to be worth standardizing.
>>>>> --
>>>>>  Nevin ":-)" Liber  <mailto:ne...@eviloverlord.com>  (847) 691-1404
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> Visit this group at
>>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>>
>>>>
>>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e0158ba0a546e00051ab8a34f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>I&#39;d be curious to see which compiler would n=
ot optimize something like that. I was at Mike Acton&#39;s presentation and=
 paid attention; I would have like to see actual numbers using relatively r=
ecent compilers, to be honest, but it&#39;s also off-topic. I understand th=
e beliefs expressed there match the worries still expressed today.<br><br><=
/div>It might require another thread, but we might need to make some measur=
ement with recent compilers about things like inlining to see how realistic=
 some beliefs are with respect to today&#39;s technology. It would help us =
target our efforts better, I think.<br><br></div>Cheers!<br></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-07-12 13:28 GMT-04:00=
 Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middleditch@=
gmail.com" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span>:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Reliance on compilers =
optimizing out overuse of abstractions is a big no-no in many industries. I=
t&#39;s the difference between having a debuggable game and having a debugg=
able slideshow.<br></div><div><br></div><div>The reason for comments like i=
n Mike Action&#39;s keynote last CppCon (&quot;we just want C99&quot;) isn&=
#39;t because game developers hate abstraction or that they&#39;re not usef=
ul, but because C++ imposes too high of a penalty for using abstractions, u=
p until you rely on compiler optimizations (and then pay the cost of slower=
 developer iteration times).</div><div><br></div><div><div>(veering off top=
ic, sorry)<br></div><div><br></div><div>That said, I admit that not everyon=
e (even in games) has the same levels of perf requirements that some of us =
do, so having unstable_remove in the stdlib isn&#39;t entirely pointless. :=
)</div><div><span class=3D""><br>On Sunday, July 12, 2015 at 7:35:22 AM UTC=
-7, Patrice Roy wrote:</span><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><span =
class=3D""><div dir=3D"ltr">It is simple (although it&#39;s also simple to =
mess-up :) ). I doubt you&#39;d be =C2=ABpaying the cost for umpteen layers=
 of abstraction with a standard container and the algorithm library=C2=BB w=
ith somtehing so easy to inline, that being said.<br></div></span><div><div=
 class=3D"h5"><div><br><div class=3D"gmail_quote">2015-07-12 3:27 GMT-04:00=
 Sean Middleditch <span dir=3D"ltr">&lt;<a rel=3D"nofollow">sean.mid...@gma=
il.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I=
&#39;ve always just called it swap-and-pop. (perhaps a misnomer, since one =
wouldn&#39;t actually _swap_... it&#39;s more like move-and-pop, I guess.)<=
div><br></div><div>Literally just used it like two hours ago, too, and I&#3=
9;m pretty sure I&#39;m about to use it again in a debug draw optimization =
refactor... and there&#39;s no card shuffling in sight. :p</div><div><br></=
div><div>Super useful for cache-friendly data stores (it&#39;s O(1) defragm=
entation/compaction). Game objects/components, particle engines, etc. Somet=
imes needs to be paired with an indirection table (e.g. <a href=3D"http://b=
itsquid.blogspot.com/2011/09/managing-decoupling-part-4-id-lookup.html" rel=
=3D"nofollow" target=3D"_blank">http://bitsquid.blogspot.com/2011/09/managi=
ng-decoupling-part-4-id-lookup.html</a> ).</div><div><br></div><div>That sa=
id, yeah, I&#39;m not sure how useful it would be to standardize. It&#39;s =
so small and simple of a micro-algorithm that I can&#39;t ever imagine want=
ing to include &lt;algorithm&gt; just to condense two or three lines into o=
ne. Also, in my experience it ends up being used in the kinds of algorithms=
 and data structures where paying the cost for umpteen layers of abstractio=
n with a standard container and the algorithm library is totally not worth =
the lazy factor. :p</div><div><br></div><div><span>On Wednesday, July 8, 20=
15 at 12:29:09 PM UTC-7, Patrice Roy wrote:</span><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span><div dir=3D"ltr"><div>I know many in the game industry=
 use a variant of this, usually called erase_with_last_swap(), as O(1) remo=
val of any element is sometimes very useful. It&#39;s always seemed to me l=
ike a nice trick to know more than a candidate for standardization; maybe I=
&#39;m wrong. It does not smell like a candidate to become a member functio=
n to me, though.<code><br></code></div></div></span><div><br><div class=3D"=
gmail_quote">2015-07-08 10:55 GMT-04:00 Nevin Liber <span dir=3D"ltr">&lt;<=
a rel=3D"nofollow">ne...@eviloverlord.com</a>&gt;</span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div><span><div class=3D"gmail_quote"><sp=
an>On 8 July 2015 at 09:46, Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">aymeri...@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>I exposed this idea here to see if oth=
er people (who don&#39;t need to converse order in vector and use erase()) =
are interested or concerned by this case.<br></div></div></blockquote><div>=
<br></div></span><div>You&#39;ve provided no motivation why people would wa=
nt to do such a thing.</div><div><br></div><div>The only scenario I can thi=
nk of is dealing cards, and that just doesn&#39;t come up often enough to b=
e worth standardizing.</div></div></span><span><font color=3D"#888888">-- <=
br><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a rel=3D"nofoll=
ow">ne...@eviloverlord.com</a>&gt;=C2=A0 <a value=3D"+18476911404">(847) 69=
1-1404</a></div>
</font></span></div></div><div><div><span>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</blockquote></div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0158ba0a546e00051ab8a34f--

.

--f46d04428e44480a92051ab98635
Content-Type: text/plain; charset=UTF-8

On 12 July 2015 at 17:35, John Bytheway <jbytheway@gmail.com> wrote:

> For what it's worth, I was not thinking about std::list so much as other
> vector-like containers (e.g. your locally developed game engine's simple
> and optimized vector-like class).  Maybe std::deque and std::string
> (although it would be quite odd to use it with string).  But the genius
> of the STL is that standard algorithms work with non-standard (i.e. not
> in the standard library) containers.
>

How is that going to work with this idea?  This algorithm needs the whole
container and not just iterators.

>
> Personally I would make it valid for std::list, without a specialization
> (because it's not a serious pessimization; could even be faster in some
> cases due to touching hotter cache lines),


Huh?

The only example of this algorithm requires picking an element at random
from the container to start with. For std::list, that is O(N).  Could you
show example code how this is cache friendly?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--f46d04428e44480a92051ab98635
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 July 2015 at 17:35, John Bytheway <span dir=3D"ltr">=
&lt;<a href=3D"mailto:jbytheway@gmail.com" target=3D"_blank">jbytheway@gmai=
l.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gma=
il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex">For what it&#39;s worth, I was not=
 thinking about std::list so much as other<br>
vector-like containers (e.g. your locally developed game engine&#39;s simpl=
e<br>
and optimized vector-like class).=C2=A0 Maybe std::deque and std::string<br=
>
(although it would be quite odd to use it with string).=C2=A0 But the geniu=
s<br>
of the STL is that standard algorithms work with non-standard (i.e. not<br>
in the standard library) containers.<br></blockquote><div><br></div><div>Ho=
w is that going to work with this idea?=C2=A0 This algorithm needs the whol=
e container and not just iterators.=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
<br>
Personally I would make it valid for std::list, without a specialization<br=
>
(because it&#39;s not a serious pessimization; could even be faster in some=
<br>
cases due to touching hotter cache lines), </blockquote><div><br></div><div=
>Huh?</div><div><br></div><div>The only example of this algorithm requires =
picking an element at random from the container to start with. For std::lis=
t, that is O(N).=C2=A0 Could you show example code how this is cache friend=
ly?</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&=
quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" targ=
et=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d04428e44480a92051ab98635--

.

--047d7b5d88ed4e85e5051ab9928c
Content-Type: text/plain; charset=UTF-8

On 12 July 2015 at 21:39, Patrice Roy <patricer@gmail.com> wrote:

> I'd be curious to see which compiler would not optimize something like
> that. I was at Mike Acton's presentation and paid attention; I would have
> like to see actual numbers using relatively recent compilers, to be honest,
> but it's also off-topic. I understand the beliefs expressed there match the
> worries still expressed today.
>

+1.  If there aren't measurements, it's just FUD.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b5d88ed4e85e5051ab9928c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 July 2015 at 21:39, Patrice Roy <span dir=3D"ltr">&l=
t;<a href=3D"mailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.co=
m</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I&#39;d be =
curious to see which compiler would not optimize something like that. I was=
 at Mike Acton&#39;s presentation and paid attention; I would have like to =
see actual numbers using relatively recent compilers, to be honest, but it&=
#39;s also off-topic. I understand the beliefs expressed there match the wo=
rries still expressed today.<br></div></div></div></blockquote><div><br></d=
iv><div>+1.=C2=A0 If there aren&#39;t measurements, it&#39;s just FUD.=C2=
=A0</div></div>-- <br><div class=3D"gmail_signature">=C2=A0Nevin &quot;:-)&=
quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" targ=
et=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b5d88ed4e85e5051ab9928c--

.

--f46d044286f4bf831e051ab9efb7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sun, Jul 12, 2015 at 8:42 PM, Nevin Liber <nevin@eviloverlord.com> wrote=
:

> On 12 July 2015 at 17:35, John Bytheway <jbytheway@gmail.com> wrote:
>
>> For what it's worth, I was not thinking about std::list so much as other
>> vector-like containers (e.g. your locally developed game engine's simple
>> and optimized vector-like class).  Maybe std::deque and std::string
>> (although it would be quite odd to use it with string).  But the genius
>> of the STL is that standard algorithms work with non-standard (i.e. not
>> in the standard library) containers.
>>
>
> How is that going to work with this idea?  This algorithm needs the whole
> container and not just iterators.
>

I think it would make sense to defer the "algorithm that operates on a
container" part of this proposal until "STL v2" is completely worked out
for all existing algorithms. (By "STL v2", I mean the version of the STL
that would let us do sort(v) in place of sort(begin(v),end(v)). I'm sure
it's coming someday; probably not in C++17, but eventually.)  Anyway, it'll
end up working the same way for myvector as for std::vector =E2=80=94 it'll=
 be a
generic algorithm that calls c.erase(...) for whatever container c you pass
in.  No big deal.

Personally I would make it valid for std::list, without a specialization
>> (because it's not a serious pessimization; could even be faster in some
>> cases due to touching hotter cache lines),
>
>
> Huh?
>
> The only example of this algorithm requires picking an element at random
> from the container to start with. For std::list, that is O(N).  Could you
> show example code how this is cache friendly?
>

Nevin, you've somehow gotten confused into the idea that this algorithm is
somehow related to card-shuffling, or random_shuffle, or something. It's
definitely not. The original idea was maybe phrased in terms of erasing an
*arbitrary* element, but that didn't imply a *randomly selected* element.

The core idea is that "erasing item J from an unsorted vector" can be
efficiently implemented as "swapping items J and N-1, and then erasing item
N-1 from the vector".

This comes up over and over in real-world code implementing "unsorted flat
collection of objects" =E2=80=94 any time we need O(1) insertion and deleti=
on and
are willing to accept O(N) search as the tradeoff. We've all done it a
million times.

The "cache friendliness" argument is valid: For any arbitrary element E
that we might want to erase from an unsorted list L, it is astronomically
more likely that *(E is in cache and L.back() is in cache)* than it is
likely that *(X is in cache for all X between E and L.back())*.

=E2=80=93Arthur

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--f46d044286f4bf831e051ab9efb7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, Jul 12, 2015 at 8:42 PM, Nevin Liber <span dir=3D"=
ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@=
eviloverlord.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div c=
lass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On 12 =
July 2015 at 17:35, John Bytheway <span dir=3D"ltr">&lt;<a href=3D"mailto:j=
bytheway@gmail.com" target=3D"_blank">jbytheway@gmail.com</a>&gt;</span> wr=
ote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">For what it&#39;s worth, I was not thinking about std::li=
st so much as other<br>
vector-like containers (e.g. your locally developed game engine&#39;s simpl=
e<br>
and optimized vector-like class).=C2=A0 Maybe std::deque and std::string<br=
>
(although it would be quite odd to use it with string).=C2=A0 But the geniu=
s<br>
of the STL is that standard algorithms work with non-standard (i.e. not<br>
in the standard library) containers.<br></blockquote><div><br></div><div>Ho=
w is that going to work with this idea?=C2=A0 This algorithm needs the whol=
e container and not just iterators.</div></div></div></div></blockquote><di=
v><br></div><div>I think it would make sense to defer the &quot;algorithm t=
hat operates on a container&quot; part of this proposal until &quot;STL v2&=
quot; is completely worked out for all existing algorithms. (By &quot;STL v=
2&quot;, I mean the version of the STL that would let us do <font face=3D"m=
onospace, monospace">sort(v)</font> in place of <font face=3D"monospace, mo=
nospace">sort(begin(v),end(v))</font>. I&#39;m sure it&#39;s coming someday=
; probably not in C++17, but eventually.) =C2=A0Anyway, it&#39;ll end up wo=
rking the same way for <font face=3D"monospace, monospace">myvector</font> =
as for <font face=3D"monospace, monospace">std::vector</font> =E2=80=94 it&=
#39;ll be a generic algorithm that calls <font face=3D"monospace, monospace=
">c.erase(...)</font> for whatever container <font face=3D"monospace, monos=
pace">c</font> you pass in.=C2=A0 No big deal.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex">Personally I would make i=
t valid for std::list, without a specialization<br>
(because it&#39;s not a serious pessimization; could even be faster in some=
<br>
cases due to touching hotter cache lines), </blockquote><div><br></div><div=
>Huh?</div><div><br></div><div>The only example of this algorithm requires =
picking an element at random from the container to start with. For std::lis=
t, that is O(N).=C2=A0 Could you show example code how this is cache friend=
ly?</div></div></div></div></blockquote><div><br></div><div>Nevin, you&#39;=
ve somehow gotten confused into the idea that this algorithm is somehow rel=
ated to card-shuffling, or random_shuffle, or something. It&#39;s definitel=
y not. The original idea was maybe phrased in terms of erasing an <i>arbitr=
ary</i> element, but that didn&#39;t imply a <i>randomly selected</i> eleme=
nt.</div><div><br></div><div>The core idea is that &quot;erasing item J fro=
m an unsorted vector&quot; can be efficiently implemented as &quot;swapping=
 items J and N-1, and then erasing item N-1 from the vector&quot;.</div><di=
v><br></div><div>This comes up over and over in real-world code implementin=
g &quot;unsorted flat collection of objects&quot; =E2=80=94 any time we nee=
d O(1) insertion and deletion and are willing to accept O(N) search as the =
tradeoff. We&#39;ve all done it a million times.</div><div><br></div><div>T=
he &quot;cache friendliness&quot; argument is valid: For any arbitrary elem=
ent E that we might want to erase from an unsorted list L, it is astronomic=
ally more likely that <i>(E is in cache and L.back() is in cache)</i> than =
it is likely that <i>(X is in cache for all X between E and L.back())</i>.<=
/div><div><br></div><div>=E2=80=93Arthur</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d044286f4bf831e051ab9efb7--

.

--bcaec53d5b518c7a15051aba1e4e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 12 July 2015 at 23:12, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

>
> Nevin, you've somehow gotten confused into the idea that this algorithm i=
s
> somehow related to card-shuffling, or random_shuffle, or something. It's
> definitely not. The original idea was maybe phrased in terms of erasing a=
n
> *arbitrary* element, but that didn't imply a *randomly selected* element.
>

If someone can provide a use case other than something equivalent to card
shuffling (pick w/o replacement), I'd like to see it.  Examples ought to be
plentiful.


>
> The core idea is that "erasing item J from an unsorted vector" can be
> efficiently implemented as "swapping items J and N-1, and then erasing it=
em
> N-1 from the vector".
>
> This comes up over and over in real-world code implementing "unsorted fla=
t
> collection of objects" =E2=80=94 any time we need O(1) insertion and dele=
tion and
> are willing to accept O(N) search as the tradeoff. We've all done it a
> million times.
>

No, that's just repeating how the algorithm works.

After all, if you just need an arbitrary element, why not always pick the
back one?  It's O(1) for all the sequence containers.
--=20
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--bcaec53d5b518c7a15051aba1e4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 12 July 2015 at 23:12, Arthur O&#39;Dwyer <span dir=3D"=
ltr">&lt;<a href=3D"mailto:arthur.j.odwyer@gmail.com" target=3D"_blank">art=
hur.j.odwyer@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><div=
><br></div></span><div>Nevin, you&#39;ve somehow gotten confused into the i=
dea that this algorithm is somehow related to card-shuffling, or random_shu=
ffle, or something. It&#39;s definitely not. The original idea was maybe ph=
rased in terms of erasing an <i>arbitrary</i> element, but that didn&#39;t =
imply a <i>randomly selected</i> element.</div></div></div></div></blockquo=
te><div><br></div><div>If someone can provide a use case other than somethi=
ng equivalent to card shuffling (pick w/o replacement), I&#39;d like to see=
 it.=C2=A0 Examples ought to be plentiful.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><div><br></div><div>The core idea is that &quot;erasing it=
em J from an unsorted vector&quot; can be efficiently implemented as &quot;=
swapping items J and N-1, and then erasing item N-1 from the vector&quot;.<=
/div><div><br></div><div>This comes up over and over in real-world code imp=
lementing &quot;unsorted flat collection of objects&quot; =E2=80=94 any tim=
e we need O(1) insertion and deletion and are willing to accept O(N) search=
 as the tradeoff. We&#39;ve all done it a million times.</div></div></div><=
/div></blockquote><div><br></div><div>No, that&#39;s just repeating how the=
 algorithm works.</div><div><br></div><div>After all, if you just need an a=
rbitrary element, why not always pick the back one?=C2=A0 It&#39;s O(1) for=
 all the sequence containers.</div></div>-- <br><div class=3D"gmail_signatu=
re">=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:ne=
vin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=
=A0 (847) 691-1404</div>
</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--bcaec53d5b518c7a15051aba1e4e--

.

--089e011773734b8bdb051abc8ed9
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>
>  If someone can provide a use case other than something equivalent to
> card shuffling (pick w/o replacement), I'd like to see it. Examples ought
> to be plentiful.


Here are a few example uses:

In a multicast delegate which makes no guarantees about the order in which
the callbacks are made, removing a delegate does not need to maintain any
ordering.

In a system that maintains a free list / pool of expensive objects, we wish
to find the most suitable object in the pool for our current needs and
remove it from the list. This pool has to service different types of
requests and so there is no good criteria for sorting this container. As
such, order is insignificant and does not need to be maintained.

Another pooling system maintains a vector of weak pointers to objects. The
lifetime of these objects is managed elsewhere. Unlike the other pool, all
objects in this system are equally good for any job. So to retrieve an item
we always just pop from the back. Given that we use weak pointers, over
time this pool will contain a significant proportion of invalid weak
pointers. We need to occasionally remove all such invalidated pointers from
this pool to keep things tidy. unstable_remove can eliminate these pointers
for us efficiently given that order is insignificant.




On Sun, Jul 12, 2015 at 11:25 PM, Nevin Liber <nevin@eviloverlord.com>
wrote:

> On 12 July 2015 at 23:12, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
> wrote:
>
>>
>> Nevin, you've somehow gotten confused into the idea that this algorithm
>> is somehow related to card-shuffling, or random_shuffle, or something. I=
t's
>> definitely not. The original idea was maybe phrased in terms of erasing =
an
>> *arbitrary* element, but that didn't imply a *randomly selected* element=
..
>>
>
> If someone can provide a use case other than something equivalent to card
> shuffling (pick w/o replacement), I'd like to see it.  Examples ought to =
be
> plentiful.
>
>
>>
>> The core idea is that "erasing item J from an unsorted vector" can be
>> efficiently implemented as "swapping items J and N-1, and then erasing i=
tem
>> N-1 from the vector".
>>
>> This comes up over and over in real-world code implementing "unsorted
>> flat collection of objects" =E2=80=94 any time we need O(1) insertion an=
d deletion
>> and are willing to accept O(N) search as the tradeoff. We've all done it=
 a
>> million times.
>>
>
> No, that's just repeating how the algorithm works.
>
> After all, if you just need an arbitrary element, why not always pick the
> back one?  It's O(1) for all the sequence containers.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e011773734b8bdb051abc8ed9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span style=3D"font-size:12.8000001907349=
px">=C2=A0</span><span style=3D"font-size:12.8000001907349px">If someone ca=
n provide a use case other than something equivalent to card shuffling (pic=
k w/o replacement), I&#39;d like to see it.=C2=A0</span><span style=3D"font=
-size:12.8000001907349px">Examples ought to be plentiful.</span></blockquot=
e><div>=C2=A0</div>Here are a few example uses:<div><br></div><div>In a mul=
ticast delegate which makes no guarantees about the order in which the call=
backs are made, removing a delegate does not need to maintain any ordering.=
</div><div><br></div><div>In a system that maintains a free list / pool of =
expensive objects, we wish to find the most suitable object in the pool for=
 our current needs and remove it from the list. This pool has to service di=
fferent types of requests and so there is no good criteria for sorting this=
 container. As such, order is insignificant and does not need to be maintai=
ned.</div><div><br></div><div>Another pooling system maintains a vector of =
weak pointers to objects. The lifetime of these objects is managed elsewher=
e. Unlike the other pool, all objects in this system are equally good for a=
ny job. So to retrieve an item we always just pop from the back. Given that=
 we use weak pointers, over time this pool will contain a significant propo=
rtion of invalid weak pointers. We need to occasionally remove all such inv=
alidated pointers from this pool to keep things tidy. unstable_remove can e=
liminate these pointers for us efficiently given that order is insignifican=
t.</div><div><br></div><div><br></div><div><br></div></div><div class=3D"gm=
ail_extra"><br><div class=3D"gmail_quote">On Sun, Jul 12, 2015 at 11:25 PM,=
 Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com=
" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On 12 July 2015 a=
t 23:12, Arthur O&#39;Dwyer <span dir=3D"ltr">&lt;<a href=3D"mailto:arthur.=
j.odwyer@gmail.com" target=3D"_blank">arthur.j.odwyer@gmail.com</a>&gt;</sp=
an> wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><span><div><br></div></span><di=
v>Nevin, you&#39;ve somehow gotten confused into the idea that this algorit=
hm is somehow related to card-shuffling, or random_shuffle, or something. I=
t&#39;s definitely not. The original idea was maybe phrased in terms of era=
sing an <i>arbitrary</i> element, but that didn&#39;t imply a <i>randomly s=
elected</i> element.</div></div></div></div></blockquote><div><br></div></s=
pan><div>If someone can provide a use case other than something equivalent =
to card shuffling (pick w/o replacement), I&#39;d like to see it.=C2=A0 Exa=
mples ought to be plentiful.</div><span class=3D""><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cl=
ass=3D"gmail_quote"><div><br></div><div>The core idea is that &quot;erasing=
 item J from an unsorted vector&quot; can be efficiently implemented as &qu=
ot;swapping items J and N-1, and then erasing item N-1 from the vector&quot=
;.</div><div><br></div><div>This comes up over and over in real-world code =
implementing &quot;unsorted flat collection of objects&quot; =E2=80=94 any =
time we need O(1) insertion and deletion and are willing to accept O(N) sea=
rch as the tradeoff. We&#39;ve all done it a million times.</div></div></di=
v></div></blockquote><div><br></div></span><div>No, that&#39;s just repeati=
ng how the algorithm works.</div><div><br></div><div>After all, if you just=
 need an arbitrary element, why not always pick the back one?=C2=A0 It&#39;=
s O(1) for all the sequence containers.</div></div><span class=3D"">-- <br>=
<div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=
=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_=
blank">(847) 691-1404</a></div>
</span></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e011773734b8bdb051abc8ed9--

.

--Apple-Mail=_C801A7A3-3318-4B64-B4F8-D92F7EE6D0C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 13 Jul 2015, at 06:25 , Nevin Liber <nevin@eviloverlord.com> wrote:
>=20
> On 12 July 2015 at 23:12, Arthur O'Dwyer <arthur.j.odwyer@gmail.com <mail=
to:arthur.j.odwyer@gmail.com>> wrote:
>=20
> Nevin, you've somehow gotten confused into the idea that this algorithm i=
s somehow related to card-shuffling, or random_shuffle, or something. It's =
definitely not. The original idea was maybe phrased in terms of erasing an =
arbitrary element, but that didn't imply a randomly selected element.
>=20
> If someone can provide a use case other than something equivalent to card=
 shuffling (pick w/o replacement), I'd like to see it.  Examples ought to b=
e plentiful.

It=E2=80=99s an optimization. That=E2=80=99s all there is to it. vector::er=
ase(pos) has a complexity of O(end() - pos) because the vector has to move =
all elements after pos one place forward. The algorithm presented here is O=
(1) because the element to be deleted is practically swapped with the last =
element in the vector and then popped, no further moving of other elements =
required. Therefore if the order of elements in the vector is irrelevant it=
 is a faster alternative to vector::erase(pos).

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_C801A7A3-3318-4B64-B4F8-D92F7EE6D0C1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 13 Jul 2015, at 0=
6:25 , Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com" class=3D""=
>nevin@eviloverlord.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-=
newline"><div class=3D""><div dir=3D"ltr" class=3D"">On 12 July 2015 at 23:=
12, Arthur O'Dwyer <span dir=3D"ltr" class=3D"">&lt;<a href=3D"mailto:arthu=
r.j.odwyer@gmail.com" target=3D"_blank" class=3D"">arthur.j.odwyer@gmail.co=
m</a>&gt;</span> wrote:<br class=3D""><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr" class=3D""=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D""><di=
v class=3D""><br class=3D""></div></span><div class=3D"">Nevin, you've some=
how gotten confused into the idea that this algorithm is somehow related to=
 card-shuffling, or random_shuffle, or something. It's definitely not. The =
original idea was maybe phrased in terms of erasing an <i class=3D"">arbitr=
ary</i> element, but that didn't imply a <i class=3D"">randomly selected</i=
> element.</div></div></div></div></blockquote><div class=3D""><br class=3D=
""></div><div class=3D"">If someone can provide a use case other than somet=
hing equivalent to card shuffling (pick w/o replacement), I'd like to see i=
t.&nbsp; Examples ought to be plentiful.</div></div></div></div></div></blo=
ckquote><div><br class=3D""></div>It=E2=80=99s an optimization. That=E2=80=
=99s all there is to it. vector::erase(pos) has a complexity of O(end() - p=
os) because the vector has to move all elements after pos one place forward=
.. The algorithm presented here is O(1) because the element to be deleted is=
 practically swapped with the last element in the vector and then popped, n=
o further moving of other elements required. Therefore if the order of elem=
ents in the vector is irrelevant it is a faster alternative to vector::eras=
e(pos).</div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_C801A7A3-3318-4B64-B4F8-D92F7EE6D0C1--

.

------=_Part_746_1601472053.1436811392434
Content-Type: multipart/alternative;
 boundary="----=_Part_747_134626179.1436811392434"

------=_Part_747_134626179.1436811392434
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Monday, 13 July 2015 12:32:52 UTC+1, Miro Knejp wrote:
>
> It=E2=80=99s an optimization. That=E2=80=99s all there is to it. vector::=
erase(pos) has a=20
> complexity of O(end() - pos) because the vector has to move all elements=
=20
> after pos one place forward. The algorithm presented here is O(1) because=
=20
> the element to be deleted is practically swapped with the last element in=
=20
> the vector and then popped, no further moving of other elements required.=
=20
> Therefore if the order of elements in the vector is irrelevant it is a=20
> faster alternative to vector::erase(pos).
>

Which is why this is useless for std::list; std::list::erase is already=20
O(1) and doesn't require a swap.

I really don't see the cache line argument; normal list erase requires=20
accessing a, i, next(i) and prev(i) while swap-and-pop requires accessing=
=20
a, i, prev(end(a)) and prev(prev(end(a))). Even if prev(end(a)) is in cache=
=20
it won't be afterwards. Also, there's no way to implement it for=20
forward_list, so that kills the consistency argument. (Although,=20
swap-and-pop with begin(a) is a cute way of implementing=20
forward_list::erase()...)

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_747_134626179.1436811392434
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>On Monday, 13 July 2015 12:32:52 UTC+1, Miro Knejp  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:br=
eak-word"><div>It=E2=80=99s an optimization. That=E2=80=99s all there is to=
 it. vector::erase(pos) has a complexity of O(end() - pos) because the vect=
or has to move all elements after pos one place forward. The algorithm pres=
ented here is O(1) because the element to be deleted is practically swapped=
 with the last element in the vector and then popped, no further moving of =
other elements required. Therefore if the order of elements in the vector i=
s irrelevant it is a faster alternative to vector::erase(pos).<br></div></d=
iv></blockquote><div><br></div><div>Which is why this is useless for std::l=
ist; std::list::erase is already O(1) and doesn&#39;t require a swap.</div>=
<div><br></div><div>I really don&#39;t see the cache line argument; normal =
list erase requires accessing a, i, next(i) and prev(i) while swap-and-pop =
requires accessing a, i, prev(end(a)) and prev(prev(end(a))). Even if prev(=
end(a)) is in cache it won&#39;t be afterwards. Also, there&#39;s no way to=
 implement it for forward_list, so that kills the consistency argument. (Al=
though, swap-and-pop with begin(a) is a cute way of implementing forward_li=
st::erase()...)</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_747_134626179.1436811392434--
------=_Part_746_1601472053.1436811392434--

.

------=_Part_4531_1765909500.1436812025965
Content-Type: multipart/alternative;
 boundary="----=_Part_4532_1060749252.1436812025965"

------=_Part_4532_1060749252.1436812025965
Content-Type: text/plain; charset=UTF-8

On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman wrote:
>
>  If someone can provide a use case other than something equivalent to
>> card shuffling (pick w/o replacement), I'd like to see it. Examples
>> ought to be plentiful.
>
>
> Here are a few example uses:
>
> In a multicast delegate which makes no guarantees about the order in which
> the callbacks are made, removing a delegate does not need to maintain any
> ordering.
>

To remove by pointer or iterator the container needs to be stable i.e.
std::list; to remove by id you need an associative container. If you're
writing a flat map backed by vector you can provide O(1) swap-and-pop erase
yourself.


> In a system that maintains a free list / pool of expensive objects, we
> wish to find the most suitable object in the pool for our current needs and
> remove it from the list. This pool has to service different types of
> requests and so there is no good criteria for sorting this container. As
> such, order is insignificant and does not need to be maintained.
>

> Another pooling system maintains a vector of weak pointers to objects. The
> lifetime of these objects is managed elsewhere. Unlike the other pool, all
> objects in this system are equally good for any job. So to retrieve an item
> we always just pop from the back. Given that we use weak pointers, over
> time this pool will contain a significant proportion of invalid weak
> pointers. We need to occasionally remove all such invalidated pointers from
> this pool to keep things tidy. unstable_remove can eliminate these pointers
> for us efficiently given that order is insignificant.
>

Or you could use std::partition.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_4532_1060749252.1436812025965
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman  wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><span style=3D"font-size:12.8000001907349px">=C2=A0</span><span sty=
le=3D"font-size:12.8000001907349px">If someone can provide a use case other=
 than something equivalent to card shuffling (pick w/o replacement), I&#39;=
d like to see it.=C2=A0</span><span style=3D"font-size:12.8000001907349px">=
Examples ought to be plentiful.</span></blockquote><div>=C2=A0</div>Here ar=
e a few example uses:<div><br></div><div>In a multicast delegate which make=
s no guarantees about the order in which the callbacks are made, removing a=
 delegate does not need to maintain any ordering.</div></div></blockquote><=
div><br></div><div>To remove by pointer or iterator the container needs to =
be stable i.e. std::list; to remove by id you need an associative container=
.. If you&#39;re writing a flat map backed by vector you can provide O(1) sw=
ap-and-pop erase yourself.</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div>In a system that maintains a free =
list / pool of expensive objects, we wish to find the most suitable object =
in the pool for our current needs and remove it from the list. This pool ha=
s to service different types of requests and so there is no good criteria f=
or sorting this container. As such, order is insignificant and does not nee=
d to be maintained.</div></div></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><br></div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div>Another pooling system mainta=
ins a vector of weak pointers to objects. The lifetime of these objects is =
managed elsewhere. Unlike the other pool, all objects in this system are eq=
ually good for any job. So to retrieve an item we always just pop from the =
back. Given that we use weak pointers, over time this pool will contain a s=
ignificant proportion of invalid weak pointers. We need to occasionally rem=
ove all such invalidated pointers from this pool to keep things tidy. unsta=
ble_remove can eliminate these pointers for us efficiently given that order=
 is insignificant.</div></div></blockquote><div><br></div><div>Or you could=
 use std::partition.=C2=A0</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4532_1060749252.1436812025965--
------=_Part_4531_1765909500.1436812025965--

.

--001a113daefcfed553051ace25e4
Content-Type: text/plain; charset=UTF-8

>
> swap-and-pop erase yourself.


The same can be said of any algorithm. We are presenting arguments why this
algorithm is worthy of standardization.

 Or you could use std::partition.


As I have already stated in this thread, this algorithm is not the same as
std::partition.

On Mon, Jul 13, 2015 at 1:27 PM, Edward Catmur <ed@catmur.co.uk> wrote:

> On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman wrote:
>>
>>  If someone can provide a use case other than something equivalent to
>>> card shuffling (pick w/o replacement), I'd like to see it. Examples
>>> ought to be plentiful.
>>
>>
>> Here are a few example uses:
>>
>> In a multicast delegate which makes no guarantees about the order in
>> which the callbacks are made, removing a delegate does not need to maintain
>> any ordering.
>>
>
> To remove by pointer or iterator the container needs to be stable i.e.
> std::list; to remove by id you need an associative container. If you're
> writing a flat map backed by vector you can provide O(1) swap-and-pop erase
> yourself.
>
>
>> In a system that maintains a free list / pool of expensive objects, we
>> wish to find the most suitable object in the pool for our current needs and
>> remove it from the list. This pool has to service different types of
>> requests and so there is no good criteria for sorting this container. As
>> such, order is insignificant and does not need to be maintained.
>>
>
>> Another pooling system maintains a vector of weak pointers to objects.
>> The lifetime of these objects is managed elsewhere. Unlike the other pool,
>> all objects in this system are equally good for any job. So to retrieve an
>> item we always just pop from the back. Given that we use weak pointers,
>> over time this pool will contain a significant proportion of invalid weak
>> pointers. We need to occasionally remove all such invalidated pointers from
>> this pool to keep things tidy. unstable_remove can eliminate these pointers
>> for us efficiently given that order is insignificant.
>>
>
> Or you could use std::partition.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113daefcfed553051ace25e4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><span style=3D"font-size:12.8000001907349=
px">swap-and-pop erase yourself.</span></blockquote><div><br></div><div>The=
 same can be said of any algorithm. We are presenting arguments why this al=
gorithm is worthy of standardization.=C2=A0</div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:=
1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left=
:1ex">=C2=A0<span style=3D"font-size:12.8000001907349px">Or you could use s=
td::partition.</span></blockquote><div><br></div><div>As I have already sta=
ted in this thread, this algorithm is not the same as std::partition.</div>=
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul=
 13, 2015 at 1:27 PM, Edward Catmur <span dir=3D"ltr">&lt;<a href=3D"mailto=
:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Monda=
y, 13 July 2015 08:20:28 UTC+1, Brent Friedman  wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><span style=3D"font-si=
ze:12.8000001907349px">=C2=A0</span><span style=3D"font-size:12.80000019073=
49px">If someone can provide a use case other than something equivalent to =
card shuffling (pick w/o replacement), I&#39;d like to see it.=C2=A0</span>=
<span style=3D"font-size:12.8000001907349px">Examples ought to be plentiful=
..</span></blockquote><div>=C2=A0</div>Here are a few example uses:<div><br>=
</div><div>In a multicast delegate which makes no guarantees about the orde=
r in which the callbacks are made, removing a delegate does not need to mai=
ntain any ordering.</div></div></blockquote><div><br></div></span><div>To r=
emove by pointer or iterator the container needs to be stable i.e. std::lis=
t; to remove by id you need an associative container. If you&#39;re writing=
 a flat map backed by vector you can provide O(1) swap-and-pop erase yourse=
lf.</div><span class=3D""><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>In a system that maintains a free list / pool=
 of expensive objects, we wish to find the most suitable object in the pool=
 for our current needs and remove it from the list. This pool has to servic=
e different types of requests and so there is no good criteria for sorting =
this container. As such, order is insignificant and does not need to be mai=
ntained.</div></div></blockquote><blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><br></div></blockquote><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>Another pooling system maintains a vector of weak =
pointers to objects. The lifetime of these objects is managed elsewhere. Un=
like the other pool, all objects in this system are equally good for any jo=
b. So to retrieve an item we always just pop from the back. Given that we u=
se weak pointers, over time this pool will contain a significant proportion=
 of invalid weak pointers. We need to occasionally remove all such invalida=
ted pointers from this pool to keep things tidy. unstable_remove can elimin=
ate these pointers for us efficiently given that order is insignificant.</d=
iv></div></blockquote><div><br></div></span><div>Or you could use std::part=
ition.=C2=A0</div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113daefcfed553051ace25e4--

.

--001a113daefc984f7e051acfb863
Content-Type: text/plain; charset=UTF-8

As a point of comparison I created a test scenario in my fork of the SG14
github branch. It's posted here if you wish to see the code.
https://github.com/schmaltzlicker/SG14

On my machine and test scenario, unstable_remove_if is a ~1.35x speedup
over partition. This is because the class is not move-friendly, so swap
incurs overhead in copying memory several times. unstable_remove_if does
not have that same overhead.
Critiques welcome.

On Mon, Jul 13, 2015 at 11:19 PM, Brent Friedman <fourthgeek@gmail.com>
wrote:

> swap-and-pop erase yourself.
>
>
> The same can be said of any algorithm. We are presenting arguments why
> this algorithm is worthy of standardization.
>
>  Or you could use std::partition.
>
>
> As I have already stated in this thread, this algorithm is not the same as
> std::partition.
>
> On Mon, Jul 13, 2015 at 1:27 PM, Edward Catmur <ed@catmur.co.uk> wrote:
>
>> On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman wrote:
>>>
>>>  If someone can provide a use case other than something equivalent to
>>>> card shuffling (pick w/o replacement), I'd like to see it. Examples
>>>> ought to be plentiful.
>>>
>>>
>>> Here are a few example uses:
>>>
>>> In a multicast delegate which makes no guarantees about the order in
>>> which the callbacks are made, removing a delegate does not need to maintain
>>> any ordering.
>>>
>>
>> To remove by pointer or iterator the container needs to be stable i.e.
>> std::list; to remove by id you need an associative container. If you're
>> writing a flat map backed by vector you can provide O(1) swap-and-pop erase
>> yourself.
>>
>>
>>> In a system that maintains a free list / pool of expensive objects, we
>>> wish to find the most suitable object in the pool for our current needs and
>>> remove it from the list. This pool has to service different types of
>>> requests and so there is no good criteria for sorting this container. As
>>> such, order is insignificant and does not need to be maintained.
>>>
>>
>>> Another pooling system maintains a vector of weak pointers to objects.
>>> The lifetime of these objects is managed elsewhere. Unlike the other pool,
>>> all objects in this system are equally good for any job. So to retrieve an
>>> item we always just pop from the back. Given that we use weak pointers,
>>> over time this pool will contain a significant proportion of invalid weak
>>> pointers. We need to occasionally remove all such invalidated pointers from
>>> this pool to keep things tidy. unstable_remove can eliminate these pointers
>>> for us efficiently given that order is insignificant.
>>>
>>
>> Or you could use std::partition.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113daefc984f7e051acfb863
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As a point of comparison I created a test scenario in my f=
ork of the SG14 github branch. It&#39;s posted here if you wish to see the =
code.<div><a href=3D"https://github.com/schmaltzlicker/SG14">https://github=
..com/schmaltzlicker/SG14</a><br></div><div><br></div><div>On my machine and=
 test scenario, unstable_remove_if is a ~1.35x speedup over partition. This=
 is because the class is not move-friendly, so swap incurs overhead in copy=
ing memory several times. unstable_remove_if does not have that same overhe=
ad.</div><div>Critiques welcome.</div></div><div class=3D"gmail_extra"><br>=
<div class=3D"gmail_quote">On Mon, Jul 13, 2015 at 11:19 PM, Brent Friedman=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:fourthgeek@gmail.com" target=3D"_b=
lank">fourthgeek@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);=
border-left-style:solid;padding-left:1ex"><span style=3D"font-size:12.80000=
01907349px">swap-and-pop erase yourself.</span></blockquote><div><br></div>=
<div>The same can be said of any algorithm. We are presenting arguments why=
 this algorithm is worthy of standardization.=C2=A0</div><span class=3D""><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left=
-style:solid;padding-left:1ex">=C2=A0<span style=3D"font-size:12.8000001907=
349px">Or you could use std::partition.</span></blockquote><div><br></div><=
/span><div>As I have already stated in this thread, this algorithm is not t=
he same as std::partition.</div></div><div class=3D"HOEnZb"><div class=3D"h=
5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Jul 13=
, 2015 at 1:27 PM, Edward Catmur <span dir=3D"ltr">&lt;<a href=3D"mailto:ed=
@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Monday, 13 July 201=
5 08:20:28 UTC+1, Brent Friedman  wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><span style=3D"font-size:12.80000019=
07349px">=C2=A0</span><span style=3D"font-size:12.8000001907349px">If someo=
ne can provide a use case other than something equivalent to card shuffling=
 (pick w/o replacement), I&#39;d like to see it.=C2=A0</span><span style=3D=
"font-size:12.8000001907349px">Examples ought to be plentiful.</span></bloc=
kquote><div>=C2=A0</div>Here are a few example uses:<div><br></div><div>In =
a multicast delegate which makes no guarantees about the order in which the=
 callbacks are made, removing a delegate does not need to maintain any orde=
ring.</div></div></blockquote><div><br></div></span><div>To remove by point=
er or iterator the container needs to be stable i.e. std::list; to remove b=
y id you need an associative container. If you&#39;re writing a flat map ba=
cked by vector you can provide O(1) swap-and-pop erase yourself.</div><span=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>In a system that maintains a free list / pool of expensive objects, we=
 wish to find the most suitable object in the pool for our current needs an=
d remove it from the list. This pool has to service different types of requ=
ests and so there is no good criteria for sorting this container. As such, =
order is insignificant and does not need to be maintained.</div></div></blo=
ckquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br></div>=
</blockquote><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>=
Another pooling system maintains a vector of weak pointers to objects. The =
lifetime of these objects is managed elsewhere. Unlike the other pool, all =
objects in this system are equally good for any job. So to retrieve an item=
 we always just pop from the back. Given that we use weak pointers, over ti=
me this pool will contain a significant proportion of invalid weak pointers=
.. We need to occasionally remove all such invalidated pointers from this po=
ol to keep things tidy. unstable_remove can eliminate these pointers for us=
 efficiently given that order is insignificant.</div></div></blockquote><di=
v><br></div></span><div>Or you could use std::partition.=C2=A0</div></div><=
div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113daefc984f7e051acfb863--

.

--047d7bb042722cab3e051ad00b6a
Content-Type: text/plain; charset=UTF-8

That makes sense; I can see the benefit over std::partition. Can I suggest
that you submit unstable_remove_if to Boost.Algorithm? It wouldn't hurt its
chances of standardization and would give it further exposure.
On 14 Jul 2015 07:12, "Brent Friedman" <fourthgeek@gmail.com> wrote:

> As a point of comparison I created a test scenario in my fork of the SG14
> github branch. It's posted here if you wish to see the code.
> https://github.com/schmaltzlicker/SG14
>
> On my machine and test scenario, unstable_remove_if is a ~1.35x speedup
> over partition. This is because the class is not move-friendly, so swap
> incurs overhead in copying memory several times. unstable_remove_if does
> not have that same overhead.
> Critiques welcome.
>
> On Mon, Jul 13, 2015 at 11:19 PM, Brent Friedman <fourthgeek@gmail.com>
> wrote:
>
>> swap-and-pop erase yourself.
>>
>>
>> The same can be said of any algorithm. We are presenting arguments why
>> this algorithm is worthy of standardization.
>>
>>  Or you could use std::partition.
>>
>>
>> As I have already stated in this thread, this algorithm is not the same
>> as std::partition.
>>
>> On Mon, Jul 13, 2015 at 1:27 PM, Edward Catmur <ed@catmur.co.uk> wrote:
>>
>>> On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman wrote:
>>>>
>>>>  If someone can provide a use case other than something equivalent to
>>>>> card shuffling (pick w/o replacement), I'd like to see it. Examples
>>>>> ought to be plentiful.
>>>>
>>>>
>>>> Here are a few example uses:
>>>>
>>>> In a multicast delegate which makes no guarantees about the order in
>>>> which the callbacks are made, removing a delegate does not need to maintain
>>>> any ordering.
>>>>
>>>
>>> To remove by pointer or iterator the container needs to be stable i.e.
>>> std::list; to remove by id you need an associative container. If you're
>>> writing a flat map backed by vector you can provide O(1) swap-and-pop erase
>>> yourself.
>>>
>>>
>>>> In a system that maintains a free list / pool of expensive objects, we
>>>> wish to find the most suitable object in the pool for our current needs and
>>>> remove it from the list. This pool has to service different types of
>>>> requests and so there is no good criteria for sorting this container. As
>>>> such, order is insignificant and does not need to be maintained.
>>>>
>>>
>>>> Another pooling system maintains a vector of weak pointers to objects.
>>>> The lifetime of these objects is managed elsewhere. Unlike the other pool,
>>>> all objects in this system are equally good for any job. So to retrieve an
>>>> item we always just pop from the back. Given that we use weak pointers,
>>>> over time this pool will contain a significant proportion of invalid weak
>>>> pointers. We need to occasionally remove all such invalidated pointers from
>>>> this pool to keep things tidy. unstable_remove can eliminate these pointers
>>>> for us efficiently given that order is insignificant.
>>>>
>>>
>>> Or you could use std::partition.
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bb042722cab3e051ad00b6a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">That makes sense; I can see the benefit over std::partition.=
 Can I suggest that you submit unstable_remove_if to Boost.Algorithm? It wo=
uldn&#39;t hurt its chances of standardization and would give it further ex=
posure. </p>
<div class=3D"gmail_quote">On 14 Jul 2015 07:12, &quot;Brent Friedman&quot;=
 &lt;<a href=3D"mailto:fourthgeek@gmail.com">fourthgeek@gmail.com</a>&gt; w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">As a point of comparison I created a test scenario in my fork of the SG1=
4 github branch. It&#39;s posted here if you wish to see the code.<div><a h=
ref=3D"https://github.com/schmaltzlicker/SG14" target=3D"_blank">https://gi=
thub.com/schmaltzlicker/SG14</a><br></div><div><br></div><div>On my machine=
 and test scenario, unstable_remove_if is a ~1.35x speedup over partition. =
This is because the class is not move-friendly, so swap incurs overhead in =
copying memory several times. unstable_remove_if does not have that same ov=
erhead.</div><div>Critiques welcome.</div></div><div class=3D"gmail_extra">=
<br><div class=3D"gmail_quote">On Mon, Jul 13, 2015 at 11:19 PM, Brent Frie=
dman <span dir=3D"ltr">&lt;<a href=3D"mailto:fourthgeek@gmail.com" target=
=3D"_blank">fourthgeek@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex"><span style=3D"font-size:12=
..8000001907349px">swap-and-pop erase yourself.</span></blockquote><div><br>=
</div><div>The same can be said of any algorithm. We are presenting argumen=
ts why this algorithm is worthy of standardization.=C2=A0</div><span><div><=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">=C2=A0<span style=3D"font-size:12.8000001907349px=
">Or you could use std::partition.</span></blockquote><div><br></div></span=
><div>As I have already stated in this thread, this algorithm is not the sa=
me as std::partition.</div></div><div><div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Mon, Jul 13, 2015 at 1:27 PM, Edward Catmur <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed=
@catmur.co.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
dir=3D"ltr"><span>On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman  w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1p=
x;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1=
ex"><span style=3D"font-size:12.8000001907349px">=C2=A0</span><span style=
=3D"font-size:12.8000001907349px">If someone can provide a use case other t=
han something equivalent to card shuffling (pick w/o replacement), I&#39;d =
like to see it.=C2=A0</span><span style=3D"font-size:12.8000001907349px">Ex=
amples ought to be plentiful.</span></blockquote><div>=C2=A0</div>Here are =
a few example uses:<div><br></div><div>In a multicast delegate which makes =
no guarantees about the order in which the callbacks are made, removing a d=
elegate does not need to maintain any ordering.</div></div></blockquote><di=
v><br></div></span><div>To remove by pointer or iterator the container need=
s to be stable i.e. std::list; to remove by id you need an associative cont=
ainer. If you&#39;re writing a flat map backed by vector you can provide O(=
1) swap-and-pop erase yourself.</div><span><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><div>In a system that maintains a=
 free list / pool of expensive objects, we wish to find the most suitable o=
bject in the pool for our current needs and remove it from the list. This p=
ool has to service different types of requests and so there is no good crit=
eria for sorting this container. As such, order is insignificant and does n=
ot need to be maintained.</div></div></blockquote><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><br></div></blockquote><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>Another pooling system maintains =
a vector of weak pointers to objects. The lifetime of these objects is mana=
ged elsewhere. Unlike the other pool, all objects in this system are equall=
y good for any job. So to retrieve an item we always just pop from the back=
.. Given that we use weak pointers, over time this pool will contain a signi=
ficant proportion of invalid weak pointers. We need to occasionally remove =
all such invalidated pointers from this pool to keep things tidy. unstable_=
remove can eliminate these pointers for us efficiently given that order is =
insignificant.</div></div></blockquote><div><br></div></span><div>Or you co=
uld use std::partition.=C2=A0</div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bb042722cab3e051ad00b6a--

.

------=_Part_1436_2024816622.1436874488897
Content-Type: multipart/alternative;
 boundary="----=_Part_1437_993055410.1436874488897"

------=_Part_1437_993055410.1436874488897
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I guess It unstable_remove (It begin, It end, T value) could be proposed=20
too?

Le mardi 14 juillet 2015 08:35:29 UTC+2, Edward Catmur a =C3=A9crit :
>
> That makes sense; I can see the benefit over std::partition. Can I sugges=
t=20
> that you submit unstable_remove_if to Boost.Algorithm? It wouldn't hurt i=
ts=20
> chances of standardization and would give it further exposure.=20
> On 14 Jul 2015 07:12, "Brent Friedman" <fourt...@gmail.com <javascript:>>=
=20
> wrote:
>
>> As a point of comparison I created a test scenario in my fork of the SG1=
4=20
>> github branch. It's posted here if you wish to see the code.
>> https://github.com/schmaltzlicker/SG14
>>
>> On my machine and test scenario, unstable_remove_if is a ~1.35x speedup=
=20
>> over partition. This is because the class is not move-friendly, so swap=
=20
>> incurs overhead in copying memory several times. unstable_remove_if does=
=20
>> not have that same overhead.
>> Critiques welcome.
>>
>> On Mon, Jul 13, 2015 at 11:19 PM, Brent Friedman <fourt...@gmail.com=20
>> <javascript:>> wrote:
>>
>>> swap-and-pop erase yourself.
>>>
>>>
>>> The same can be said of any algorithm. We are presenting arguments why=
=20
>>> this algorithm is worthy of standardization.=20
>>>
>>>  Or you could use std::partition.
>>>
>>>
>>> As I have already stated in this thread, this algorithm is not the same=
=20
>>> as std::partition.
>>>
>>> On Mon, Jul 13, 2015 at 1:27 PM, Edward Catmur <e...@catmur.co.uk=20
>>> <javascript:>> wrote:
>>>
>>>> On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman wrote:
>>>>>
>>>>>  If someone can provide a use case other than something equivalent to=
=20
>>>>>> card shuffling (pick w/o replacement), I'd like to see it. Examples=
=20
>>>>>> ought to be plentiful.
>>>>>
>>>>> =20
>>>>> Here are a few example uses:
>>>>>
>>>>> In a multicast delegate which makes no guarantees about the order in=
=20
>>>>> which the callbacks are made, removing a delegate does not need to ma=
intain=20
>>>>> any ordering.
>>>>>
>>>>
>>>> To remove by pointer or iterator the container needs to be stable i.e.=
=20
>>>> std::list; to remove by id you need an associative container. If you'r=
e=20
>>>> writing a flat map backed by vector you can provide O(1) swap-and-pop =
erase=20
>>>> yourself.
>>>> =20
>>>>
>>>>> In a system that maintains a free list / pool of expensive objects, w=
e=20
>>>>> wish to find the most suitable object in the pool for our current nee=
ds and=20
>>>>> remove it from the list. This pool has to service different types of=
=20
>>>>> requests and so there is no good criteria for sorting this container.=
 As=20
>>>>> such, order is insignificant and does not need to be maintained.
>>>>>
>>>>
>>>>> Another pooling system maintains a vector of weak pointers to objects=
..=20
>>>>> The lifetime of these objects is managed elsewhere. Unlike the other =
pool,=20
>>>>> all objects in this system are equally good for any job. So to retrie=
ve an=20
>>>>> item we always just pop from the back. Given that we use weak pointer=
s,=20
>>>>> over time this pool will contain a significant proportion of invalid =
weak=20
>>>>> pointers. We need to occasionally remove all such invalidated pointer=
s from=20
>>>>> this pool to keep things tidy. unstable_remove can eliminate these po=
inters=20
>>>>> for us efficiently given that order is insignificant.
>>>>>
>>>>
>>>> Or you could use std::partition.=20
>>>>
>>>> --=20
>>>>
>>>> ---=20
>>>> You received this message because you are subscribed to the Google=20
>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send=
=20
>>>> an email to std-proposal...@isocpp.org <javascript:>.
>>>> To post to this group, send email to std-pr...@isocpp.org <javascript:=
>
>>>> .
>>>> Visit this group at=20
>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>
>>>
>>>
>>  --=20
>>
>> ---=20
>> You received this message because you are subscribed to a topic in the=
=20
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit=20
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to=20
>> std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at=20
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_1437_993055410.1436874488897
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I guess <font face=3D"courier new, monospace">It unstable_=
remove (It begin, It end, T value)</font> could be proposed too?<br><br>Le =
mardi 14 juillet 2015 08:35:29 UTC+2, Edward Catmur a =C3=A9crit=C2=A0:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">That makes sense; I=
 can see the benefit over std::partition. Can I suggest that you submit uns=
table_remove_if to Boost.Algorithm? It wouldn&#39;t hurt its chances of sta=
ndardization and would give it further exposure. </p>
<div class=3D"gmail_quote">On 14 Jul 2015 07:12, &quot;Brent Friedman&quot;=
 &lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D=
&#39;javascript:&#39;;return true;">fourt...@gmail.com</a>&gt; wrote:<br ty=
pe=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">As a poi=
nt of comparison I created a test scenario in my fork of the SG14 github br=
anch. It&#39;s posted here if you wish to see the code.<div><a href=3D"http=
s://github.com/schmaltzlicker/SG14" target=3D"_blank" rel=3D"nofollow" onmo=
usedown=3D"this.href=3D&#39;https://www.google.com/url?q\75https%3A%2F%2Fgi=
thub.com%2Fschmaltzlicker%2FSG14\46sa\75D\46sntz\0751\46usg\75AFQjCNGZhVJFP=
_PPgORsEsk47yGP9zdxBw&#39;;return true;" onclick=3D"this.href=3D&#39;https:=
//www.google.com/url?q\75https%3A%2F%2Fgithub.com%2Fschmaltzlicker%2FSG14\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNGZhVJFP_PPgORsEsk47yGP9zdxBw&#39;;return =
true;">https://github.com/schmaltzlicker/SG14</a><br></div><div><br></div><=
div>On my machine and test scenario, unstable_remove_if is a ~1.35x speedup=
 over partition. This is because the class is not move-friendly, so swap in=
curs overhead in copying memory several times. unstable_remove_if does not =
have that same overhead.</div><div>Critiques welcome.</div></div><div><br><=
div class=3D"gmail_quote">On Mon, Jul 13, 2015 at 11:19 PM, Brent Friedman =
<span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">fourt...@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex"><span style=3D"font-size:12.8000001907349px">swap-and-pop erase=
 yourself.</span></blockquote><div><br></div><div>The same can be said of a=
ny algorithm. We are presenting arguments why this algorithm is worthy of s=
tandardization.=C2=A0</div><span><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=C2=A0<spa=
n style=3D"font-size:12.8000001907349px">Or you could use std::partition.</=
span></blockquote><div><br></div></span><div>As I have already stated in th=
is thread, this algorithm is not the same as std::partition.</div></div><di=
v><div><div><br><div class=3D"gmail_quote">On Mon, Jul 13, 2015 at 1:27 PM,=
 Edward Catmur <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">e...@ca=
tmur.co.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><span>On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman  wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><span style=3D"font-size:12.8000001907349px">=C2=A0</span><span style=3D"f=
ont-size:12.8000001907349px">If someone can provide a use case other than s=
omething equivalent to card shuffling (pick w/o replacement), I&#39;d like =
to see it.=C2=A0</span><span style=3D"font-size:12.8000001907349px">Example=
s ought to be plentiful.</span></blockquote><div>=C2=A0</div>Here are a few=
 example uses:<div><br></div><div>In a multicast delegate which makes no gu=
arantees about the order in which the callbacks are made, removing a delega=
te does not need to maintain any ordering.</div></div></blockquote><div><br=
></div></span><div>To remove by pointer or iterator the container needs to =
be stable i.e. std::list; to remove by id you need an associative container=
.. If you&#39;re writing a flat map backed by vector you can provide O(1) sw=
ap-and-pop erase yourself.</div><span><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div>In a system that maintains a free=
 list / pool of expensive objects, we wish to find the most suitable object=
 in the pool for our current needs and remove it from the list. This pool h=
as to service different types of requests and so there is no good criteria =
for sorting this container. As such, order is insignificant and does not ne=
ed to be maintained.</div></div></blockquote><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br></div></blockquote><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div>Another pooling system maintains a vec=
tor of weak pointers to objects. The lifetime of these objects is managed e=
lsewhere. Unlike the other pool, all objects in this system are equally goo=
d for any job. So to retrieve an item we always just pop from the back. Giv=
en that we use weak pointers, over time this pool will contain a significan=
t proportion of invalid weak pointers. We need to occasionally remove all s=
uch invalidated pointers from this pool to keep things tidy. unstable_remov=
e can eliminate these pointers for us efficiently given that order is insig=
nificant.</div></div></blockquote><div><br></div></span><div>Or you could u=
se std::partition.=C2=A0</div></div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmoused=
own=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg/unsubscribe" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg/unsubscribe&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/aGkpdkvXxVg/unsubscribe&#39;;return true;">https://grou=
ps.google.com/a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg/unsubscribe</a=
>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr.=
...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/isocpp=
..org/group/std-proposals/</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1437_993055410.1436874488897--
------=_Part_1436_2024816622.1436874488897--

.

--001a11c36592d35d3b051ad51652
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Do you have an efficient implementation in mind? The version using an
iterator as 3rd argument is evident to me, but this one is not. I'd like to
see the implementation if you have one. Cheers!

2015-07-14 7:48 GMT-04:00 Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com>:

> I guess It unstable_remove (It begin, It end, T value) could be proposed
> too?
>
> Le mardi 14 juillet 2015 08:35:29 UTC+2, Edward Catmur a =C3=A9crit :
>>
>> That makes sense; I can see the benefit over std::partition. Can I
>> suggest that you submit unstable_remove_if to Boost.Algorithm? It wouldn=
't
>> hurt its chances of standardization and would give it further exposure.
>> On 14 Jul 2015 07:12, "Brent Friedman" <fourt...@gmail.com> wrote:
>>
>>> As a point of comparison I created a test scenario in my fork of the
>>> SG14 github branch. It's posted here if you wish to see the code.
>>> https://github.com/schmaltzlicker/SG14
>>>
>>> On my machine and test scenario, unstable_remove_if is a ~1.35x speedup
>>> over partition. This is because the class is not move-friendly, so swap
>>> incurs overhead in copying memory several times. unstable_remove_if doe=
s
>>> not have that same overhead.
>>> Critiques welcome.
>>>
>>> On Mon, Jul 13, 2015 at 11:19 PM, Brent Friedman <fourt...@gmail.com>
>>> wrote:
>>>
>>>> swap-and-pop erase yourself.
>>>>
>>>>
>>>> The same can be said of any algorithm. We are presenting arguments why
>>>> this algorithm is worthy of standardization.
>>>>
>>>>  Or you could use std::partition.
>>>>
>>>>
>>>> As I have already stated in this thread, this algorithm is not the sam=
e
>>>> as std::partition.
>>>>
>>>> On Mon, Jul 13, 2015 at 1:27 PM, Edward Catmur <e...@catmur.co.uk>
>>>> wrote:
>>>>
>>>>> On Monday, 13 July 2015 08:20:28 UTC+1, Brent Friedman wrote:
>>>>>>
>>>>>>  If someone can provide a use case other than something equivalent
>>>>>>> to card shuffling (pick w/o replacement), I'd like to see it. Examp=
les
>>>>>>> ought to be plentiful.
>>>>>>
>>>>>>
>>>>>> Here are a few example uses:
>>>>>>
>>>>>> In a multicast delegate which makes no guarantees about the order in
>>>>>> which the callbacks are made, removing a delegate does not need to m=
aintain
>>>>>> any ordering.
>>>>>>
>>>>>
>>>>> To remove by pointer or iterator the container needs to be stable i.e=
..
>>>>> std::list; to remove by id you need an associative container. If you'=
re
>>>>> writing a flat map backed by vector you can provide O(1) swap-and-pop=
 erase
>>>>> yourself.
>>>>>
>>>>>
>>>>>> In a system that maintains a free list / pool of expensive objects,
>>>>>> we wish to find the most suitable object in the pool for our current=
 needs
>>>>>> and remove it from the list. This pool has to service different type=
s of
>>>>>> requests and so there is no good criteria for sorting this container=
.. As
>>>>>> such, order is insignificant and does not need to be maintained.
>>>>>>
>>>>>
>>>>>> Another pooling system maintains a vector of weak pointers to
>>>>>> objects. The lifetime of these objects is managed elsewhere. Unlike =
the
>>>>>> other pool, all objects in this system are equally good for any job.=
 So to
>>>>>> retrieve an item we always just pop from the back. Given that we use=
 weak
>>>>>> pointers, over time this pool will contain a significant proportion =
of
>>>>>> invalid weak pointers. We need to occasionally remove all such inval=
idated
>>>>>> pointers from this pool to keep things tidy. unstable_remove can eli=
minate
>>>>>> these pointers for us efficiently given that order is insignificant.
>>>>>>
>>>>>
>>>>> Or you could use std::partition.
>>>>>
>>>>> --
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "ISO C++ Standard - Future Proposals" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, sen=
d
>>>>> an email to std-proposal...@isocpp.org.
>>>>> To post to this group, send email to std-pr...@isocpp.org.
>>>>> Visit this group at
>>>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>>>
>>>>
>>>>
>>>  --
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/aGkpdkvXxV=
g/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>  --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c36592d35d3b051ad51652
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Do you have an efficient implementation in mind? The versi=
on using an iterator as 3rd argument is evident to me, but this one is not.=
 I&#39;d like to see the implementation if you have one. Cheers!<br></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-07-14 7:48 GM=
T-04:00 Aymeric Pell=C3=A9 <span dir=3D"ltr">&lt;<a href=3D"mailto:aymeric.=
pelle@gmail.com" target=3D"_blank">aymeric.pelle@gmail.com</a>&gt;</span>:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I guess <font face=3D"co=
urier new, monospace">It unstable_remove (It begin, It end, T value)</font>=
 could be proposed too?<span class=3D""><br><br>Le mardi 14 juillet 2015 08=
:35:29 UTC+2, Edward Catmur a =C3=A9crit=C2=A0:</span><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><span class=3D""><p dir=3D"ltr">That makes sense; I can =
see the benefit over std::partition. Can I suggest that you submit unstable=
_remove_if to Boost.Algorithm? It wouldn&#39;t hurt its chances of standard=
ization and would give it further exposure. </p>
</span><div class=3D"gmail_quote"><span class=3D"">On 14 Jul 2015 07:12, &q=
uot;Brent Friedman&quot; &lt;<a rel=3D"nofollow">fourt...@gmail.com</a>&gt;=
 wrote:<br type=3D"attribution"></span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span=
 class=3D""><div dir=3D"ltr">As a point of comparison I created a test scen=
ario in my fork of the SG14 github branch. It&#39;s posted here if you wish=
 to see the code.<div><a href=3D"https://github.com/schmaltzlicker/SG14" re=
l=3D"nofollow" target=3D"_blank">https://github.com/schmaltzlicker/SG14</a>=
<br></div><div><br></div><div>On my machine and test scenario, unstable_rem=
ove_if is a ~1.35x speedup over partition. This is because the class is not=
 move-friendly, so swap incurs overhead in copying memory several times. un=
stable_remove_if does not have that same overhead.</div><div>Critiques welc=
ome.</div></div></span><div><br><div class=3D"gmail_quote"><span class=3D""=
>On Mon, Jul 13, 2015 at 11:19 PM, Brent Friedman <span dir=3D"ltr">&lt;<a =
rel=3D"nofollow">fourt...@gmail.com</a>&gt;</span> wrote:<br></span><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><span class=3D""><div dir=3D"ltr"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<span style=3D"font-size:12.8000001907349px">swap-and-pop erase yourself.</=
span></blockquote><div><br></div><div>The same can be said of any algorithm=
.. We are presenting arguments why this algorithm is worthy of standardizati=
on.=C2=A0</div><span><div><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">=C2=A0<span style=3D"f=
ont-size:12.8000001907349px">Or you could use std::partition.</span></block=
quote><div><br></div></span><div>As I have already stated in this thread, t=
his algorithm is not the same as std::partition.</div></div></span><div><di=
v><div><br><div class=3D"gmail_quote"><span class=3D"">On Mon, Jul 13, 2015=
 at 1:27 PM, Edward Catmur <span dir=3D"ltr">&lt;<a rel=3D"nofollow">e...@c=
atmur.co.uk</a>&gt;</span> wrote:<br></span><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<span class=3D""><div dir=3D"ltr"><span>On Monday, 13 July 2015 08:20:28 UT=
C+1, Brent Friedman  wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><span style=3D"font-size:12.8000001907349px">=C2=
=A0</span><span style=3D"font-size:12.8000001907349px">If someone can provi=
de a use case other than something equivalent to card shuffling (pick w/o r=
eplacement), I&#39;d like to see it.=C2=A0</span><span style=3D"font-size:1=
2.8000001907349px">Examples ought to be plentiful.</span></blockquote><div>=
=C2=A0</div>Here are a few example uses:<div><br></div><div>In a multicast =
delegate which makes no guarantees about the order in which the callbacks a=
re made, removing a delegate does not need to maintain any ordering.</div><=
/div></blockquote><div><br></div></span><div>To remove by pointer or iterat=
or the container needs to be stable i.e. std::list; to remove by id you nee=
d an associative container. If you&#39;re writing a flat map backed by vect=
or you can provide O(1) swap-and-pop erase yourself.</div><span><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>In a sy=
stem that maintains a free list / pool of expensive objects, we wish to fin=
d the most suitable object in the pool for our current needs and remove it =
from the list. This pool has to service different types of requests and so =
there is no good criteria for sorting this container. As such, order is ins=
ignificant and does not need to be maintained.</div></div></blockquote><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br></div></blockquote=
><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Another pool=
ing system maintains a vector of weak pointers to objects. The lifetime of =
these objects is managed elsewhere. Unlike the other pool, all objects in t=
his system are equally good for any job. So to retrieve an item we always j=
ust pop from the back. Given that we use weak pointers, over time this pool=
 will contain a significant proportion of invalid weak pointers. We need to=
 occasionally remove all such invalidated pointers from this pool to keep t=
hings tidy. unstable_remove can eliminate these pointers for us efficiently=
 given that order is insignificant.</div></div></blockquote><div><br></div>=
</span><div>Or you could use std::partition.=C2=A0</div></div></span><div><=
div><span class=3D"">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div><span class=3D"">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/aGkpdkvXxVg/unsubscribe" rel=3D"nofollow=
" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/aGkpdkvXxVg/unsubscribe</a>.<br></span>
To unsubscribe from this group and all its topics, send an email to <a rel=
=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"nofollow" target=3D"_blank">http://groups.google.com=
/a/isocpp.org/group/std-proposals/</a>.<br>
</span></blockquote></div>
</blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c36592d35d3b051ad51652--

.

--Apple-Mail=_00AAB18D-343A-49D5-B047-224A141768F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 14 Jul 2015, at 13:48 , Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com> w=
rote:
>=20
> I guess It unstable_remove (It begin, It end, T value) could be proposed =
too?

How is that different from the existing remove(first, last, value)?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_00AAB18D-343A-49D5-B047-224A141768F3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 14 Jul 2015, at 1=
3:48 , Aymeric Pell=C3=A9 &lt;<a href=3D"mailto:aymeric.pelle@gmail.com" cl=
ass=3D"">aymeric.pelle@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-int=
erchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">I guess <font=
 face=3D"courier new, monospace" class=3D"">It unstable_remove (It begin, I=
t end, T value)</font> could be proposed too?<br class=3D""></div></div></b=
lockquote><div><br class=3D""></div><div>How is that different from the exi=
sting remove(first, last, value)?</div></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_00AAB18D-343A-49D5-B047-224A141768F3--

.

--Apple-Mail=_FC5E8899-1AAA-4F1A-9D4E-C651C3C297A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9307=E2=80=9314, at 8:48 PM, Miro Knejp <miro.knejp@gmail.c=
om> wrote:
>=20
>=20
>> On 14 Jul 2015, at 13:48 , Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com <=
mailto:aymeric.pelle@gmail.com>> wrote:
>>=20
>> I guess It unstable_remove (It begin, It end, T value) could be proposed=
 too?
>=20
> How is that different from the existing remove(first, last, value)?

It would be unstable, unlike the current remove. It would also require bidi=
rectional iterators (or fall back to the stable algorithm given forward ite=
rators).

unstable_remove_if would line up more closely with this discussion, though.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_FC5E8899-1AAA-4F1A-9D4E-C651C3C297A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9307=
=E2=80=9314, at 8:48 PM, Miro Knejp &lt;<a href=3D"mailto:miro.knejp@gmail.=
com" class=3D"">miro.knejp@gmail.com</a>&gt; wrote:</div><br class=3D"Apple=
-interchange-newline"><div class=3D""><meta http-equiv=3D"Content-Type" con=
tent=3D"text/html charset=3Dutf-8" class=3D""><div style=3D"word-wrap: brea=
k-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" c=
lass=3D""><br class=3D""><div class=3D""><blockquote type=3D"cite" class=3D=
""><div class=3D"">On 14 Jul 2015, at 13:48 , Aymeric Pell=C3=A9 &lt;<a hre=
f=3D"mailto:aymeric.pelle@gmail.com" class=3D"">aymeric.pelle@gmail.com</a>=
&gt; wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><d=
iv dir=3D"ltr" class=3D"">I guess <font face=3D"courier new, monospace" cla=
ss=3D"">It unstable_remove (It begin, It end, T value)</font> could be prop=
osed too?<br class=3D""></div></div></blockquote><div class=3D""><br class=
=3D""></div><div class=3D"">How is that different from the existing remove(=
first, last, value)?</div></div></div></div></blockquote><br class=3D""></d=
iv><div>It would be unstable, unlike the current <font face=3D"Courier" cla=
ss=3D"">remove</font>. It would also require bidirectional iterators (or fa=
ll back to the stable algorithm given forward iterators).</div><br class=3D=
""><div class=3D""><font face=3D"Courier" class=3D"">unstable_remove_if</fo=
nt> would line up more closely with this discussion, though.</div><div clas=
s=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_FC5E8899-1AAA-4F1A-9D4E-C651C3C297A2--

.

--047d7bb04272d98a27051ad6de3c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 14, 2015 at 1:48 PM, Miro Knejp <miro.knejp@gmail.com> wrote:

>
> On 14 Jul 2015, at 13:48 , Aymeric Pell=C3=A9 <aymeric.pelle@gmail.com> w=
rote:
>
> I guess It unstable_remove (It begin, It end, T value) could be proposed
> too?
>
>
> How is that different from the existing remove(first, last, value)?
>

It's unstable, so more efficient (fewer moves). Example:
<http://coliru.stacked-crooked.com/a/3b20a779d9535c15>

Stable, by value:       Textwithsomespaces

Unstable

, by value:     Textswithesomecaps

Stable

, by predicate:   Textwithsomewhitespaces

Unstable

, by predicate: Textsewithcsomeapsewhit

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7bb04272d98a27051ad6de3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jul 14, 2015 at 1:48 PM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>&gt;</=
span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-le=
ft-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><d=
iv><span class=3D""><blockquote type=3D"cite"><div>On 14 Jul 2015, at 13:48=
 , Aymeric Pell=C3=A9 &lt;<a href=3D"mailto:aymeric.pelle@gmail.com" target=
=3D"_blank">aymeric.pelle@gmail.com</a>&gt; wrote:</div><br><div><div dir=
=3D"ltr">I guess <font face=3D"courier new, monospace">It unstable_remove (=
It begin, It end, T value)</font> could be proposed too?<br></div></div></b=
lockquote><div><br></div></span><div>How is that different from the existin=
g remove(first, last, value)?</div></div></div></blockquote><div><br></div>=
<div>It&#39;s unstable, so more efficient (fewer moves). <a href=3D"http://=
coliru.stacked-crooked.com/a/3b20a779d9535c15">Example:</a></div><div><br><=
/div><div><div style=3D"color:rgb(0,0,0);font-family:monospace;font-size:13=
..3333330154419px;outline:0px!important"><pre class=3D"" style=3D"display:in=
line-block;margin-top:0px;margin-bottom:0px;padding:0px">Stable, by value: =
      Textwithsomespaces</pre></div><div style=3D"color:rgb(0,0,0);font-fam=
ily:monospace;font-size:13.3333330154419px;outline:0px!important"><pre clas=
s=3D"" style=3D"display:inline-block;margin-top:0px;margin-bottom:0px;paddi=
ng:0px">Unstable</pre><span style=3D"font-size:13.3333330154419px;white-spa=
ce:pre">, by value</span><span style=3D"font-size:13.3333330154419px">: =C2=
=A0 =C2=A0 Textswithesomecaps</span></div><div style=3D"color:rgb(0,0,0);fo=
nt-family:monospace;font-size:13.3333330154419px;outline:0px!important"><pr=
e class=3D"" style=3D"display:inline-block;margin-top:0px;margin-bottom:0px=
;padding:0px">Stable</pre><span style=3D"font-size:13.3333330154419px;white=
-space:pre">, by predicate</span><span style=3D"font-size:13.3333330154419p=
x">: =C2=A0 Textwithsomewhitespaces</span></div><div style=3D"color:rgb(0,0=
,0);font-family:monospace;font-size:13.3333330154419px;outline:0px!importan=
t"><pre class=3D"" style=3D"display:inline-block;margin-top:0px;margin-bott=
om:0px;padding:0px">Unstable</pre><span style=3D"font-size:13.3333330154419=
px;white-space:pre">, by predicate</span><span style=3D"font-size:13.333333=
0154419px">: Textsewithcsomeapsewhit</span></div></div><div><pre class=3D""=
 style=3D"display:inline-block;margin-top:0px;margin-bottom:0px;padding:0px=
"><br></pre></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bb04272d98a27051ad6de3c--

.

------=_Part_545_2020829616.1436888276383
Content-Type: multipart/alternative;
 boundary="----=_Part_546_1524776999.1436888276383"

------=_Part_546_1524776999.1436888276383
Content-Type: text/plain; charset=UTF-8

Sorry for the confusion but, exactly which algorithm(s) are we discussing
at present? I can think of several:

1. void unstable_erase(vector&, It position);  // erase a single element
2. void unstable_erase(vector&, It start, It end);  // erase a range of
elements
3. void unstable_erase(vector&, T const& value);  // erase all elements
having a particular value
4. void unstable_erase_if(vector&, Predicate);  // erase all elements
satisfying a predicate
5. It unstable_remove(It start, It end, T const& value);  // remove all
elements having a particular value
6. It unstable_remove_if(It start, It end, Predicate);  // remove all
elements satisfying a predicate

It seems like the original proposal was for (1), possibly as a member
function, but we appear to have moved on to discussing (6) - was that
intended?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_546_1524776999.1436888276383
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Sorry for the confusion but, exactly which algorithm(s) ar=
e we discussing at present? I can think of several:<div><br></div><div>1. v=
oid unstable_erase(vector&amp;, It position); =C2=A0// erase a single eleme=
nt</div><div>2. void unstable_erase(vector&amp;, It start, It end); =C2=A0/=
/ erase a range of elements</div><div><div><div>3. void unstable_erase(vect=
or&amp;, T const&amp; value); =C2=A0// erase all elements having a particul=
ar value</div><div>4. void unstable_erase_if(vector&amp;, Predicate); =C2=
=A0// erase all elements satisfying a predicate</div></div><div>5. It unsta=
ble_remove(It start, It end, T const&amp; value); =C2=A0// remove all eleme=
nts having a particular value</div><div>6. It unstable_remove_if(It start, =
It end, Predicate); =C2=A0// remove all elements satisfying a predicate</di=
v></div><div></div><div><br></div><div>It seems like the original proposal =
was for (1), possibly as a member function, but we appear to have moved on =
to discussing (6) - was that intended?</div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_546_1524776999.1436888276383--
------=_Part_545_2020829616.1436888276383--

.

> On 2015=E2=80=9307=E2=80=9314, at 11:37 PM, Edward Catmur <ed@catmur.co.u=
k> wrote:
>=20
> Sorry for the confusion but, exactly which algorithm(s) are we discussing=
 at present? I can think of several:
>=20
> 1. void unstable_erase(vector&, It position);  // erase a single element
> 2. void unstable_erase(vector&, It start, It end);  // erase a range of e=
lements
> 3. void unstable_erase(vector&, T const& value);  // erase all elements h=
aving a particular value
> 4. void unstable_erase_if(vector&, Predicate);  // erase all elements sat=
isfying a predicate
> 5. It unstable_remove(It start, It end, T const& value);  // remove all e=
lements having a particular value
> 6. It unstable_remove_if(It start, It end, Predicate);  // remove all ele=
ments satisfying a predicate
>=20
> It seems like the original proposal was for (1), possibly as a member fun=
ction, but we appear to have moved on to discussing (6) - was that intended=
?

I didn=E2=80=99t see anything about #5 before Aymeric mentioned it, and I w=
as already thinking of #6 so I chimed in.

However, all the discussion of actual use cases seem to be talking about #4=
.. It looks to me like #1-3 are extraneous and #5-6 might be solutions in se=
arch of a problem.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--089e0158ba0ae06899051ad8ff12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

#1 is probably the most used in practice, to be honest. #4 is cool. The
rest, not sure.

2015-07-14 11:45 GMT-04:00 David Krauss <potswa@mac.com>:

>
> > On 2015=E2=80=9307=E2=80=9314, at 11:37 PM, Edward Catmur <ed@catmur.co=
..uk> wrote:
> >
> > Sorry for the confusion but, exactly which algorithm(s) are we
> discussing at present? I can think of several:
> >
> > 1. void unstable_erase(vector&, It position);  // erase a single elemen=
t
> > 2. void unstable_erase(vector&, It start, It end);  // erase a range of
> elements
> > 3. void unstable_erase(vector&, T const& value);  // erase all elements
> having a particular value
> > 4. void unstable_erase_if(vector&, Predicate);  // erase all elements
> satisfying a predicate
> > 5. It unstable_remove(It start, It end, T const& value);  // remove all
> elements having a particular value
> > 6. It unstable_remove_if(It start, It end, Predicate);  // remove all
> elements satisfying a predicate
> >
> > It seems like the original proposal was for (1), possibly as a member
> function, but we appear to have moved on to discussing (6) - was that
> intended?
>
> I didn=E2=80=99t see anything about #5 before Aymeric mentioned it, and I=
 was
> already thinking of #6 so I chimed in.
>
> However, all the discussion of actual use cases seem to be talking about
> #4. It looks to me like #1-3 are extraneous and #5-6 might be solutions i=
n
> search of a problem.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e0158ba0ae06899051ad8ff12
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">#1 is probably the most used in practice, to be honest. #4=
 is cool. The rest, not sure.<br></div><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">2015-07-14 11:45 GMT-04:00 David Krauss <span dir=3D"=
ltr">&lt;<a href=3D"mailto:potswa@mac.com" target=3D"_blank">potswa@mac.com=
</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br>
&gt; On 2015=E2=80=9307=E2=80=9314, at 11:37 PM, Edward Catmur &lt;<a href=
=3D"mailto:ed@catmur.co.uk">ed@catmur.co.uk</a>&gt; wrote:<br>
&gt;<br>
&gt; Sorry for the confusion but, exactly which algorithm(s) are we discuss=
ing at present? I can think of several:<br>
&gt;<br>
&gt; 1. void unstable_erase(vector&amp;, It position);=C2=A0 // erase a sin=
gle element<br>
&gt; 2. void unstable_erase(vector&amp;, It start, It end);=C2=A0 // erase =
a range of elements<br>
&gt; 3. void unstable_erase(vector&amp;, T const&amp; value);=C2=A0 // eras=
e all elements having a particular value<br>
&gt; 4. void unstable_erase_if(vector&amp;, Predicate);=C2=A0 // erase all =
elements satisfying a predicate<br>
&gt; 5. It unstable_remove(It start, It end, T const&amp; value);=C2=A0 // =
remove all elements having a particular value<br>
&gt; 6. It unstable_remove_if(It start, It end, Predicate);=C2=A0 // remove=
 all elements satisfying a predicate<br>
&gt;<br>
&gt; It seems like the original proposal was for (1), possibly as a member =
function, but we appear to have moved on to discussing (6) - was that inten=
ded?<br>
<br>
</span>I didn=E2=80=99t see anything about #5 before Aymeric mentioned it, =
and I was already thinking of #6 so I chimed in.<br>
<br>
However, all the discussion of actual use cases seem to be talking about #4=
.. It looks to me like #1-3 are extraneous and #5-6 might be solutions in se=
arch of a problem.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0158ba0ae06899051ad8ff12--

.

--001a11c353e88dac30051ad901a0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Correction: #4 is cool _if_ there's an efficient implementation :)

2015-07-14 13:16 GMT-04:00 Patrice Roy <patricer@gmail.com>:

> #1 is probably the most used in practice, to be honest. #4 is cool. The
> rest, not sure.
>
> 2015-07-14 11:45 GMT-04:00 David Krauss <potswa@mac.com>:
>
>>
>> > On 2015=E2=80=9307=E2=80=9314, at 11:37 PM, Edward Catmur <ed@catmur.c=
o.uk> wrote:
>> >
>> > Sorry for the confusion but, exactly which algorithm(s) are we
>> discussing at present? I can think of several:
>> >
>> > 1. void unstable_erase(vector&, It position);  // erase a single eleme=
nt
>> > 2. void unstable_erase(vector&, It start, It end);  // erase a range o=
f
>> elements
>> > 3. void unstable_erase(vector&, T const& value);  // erase all element=
s
>> having a particular value
>> > 4. void unstable_erase_if(vector&, Predicate);  // erase all elements
>> satisfying a predicate
>> > 5. It unstable_remove(It start, It end, T const& value);  // remove al=
l
>> elements having a particular value
>> > 6. It unstable_remove_if(It start, It end, Predicate);  // remove all
>> elements satisfying a predicate
>> >
>> > It seems like the original proposal was for (1), possibly as a member
>> function, but we appear to have moved on to discussing (6) - was that
>> intended?
>>
>> I didn=E2=80=99t see anything about #5 before Aymeric mentioned it, and =
I was
>> already thinking of #6 so I chimed in.
>>
>> However, all the discussion of actual use cases seem to be talking about
>> #4. It looks to me like #1-3 are extraneous and #5-6 might be solutions =
in
>> search of a problem.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c353e88dac30051ad901a0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Correction: #4 is cool _if_ there&#39;s an efficient imple=
mentation :)<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">2015-07-14 13:16 GMT-04:00 Patrice Roy <span dir=3D"ltr">&lt;<a href=
=3D"mailto:patricer@gmail.com" target=3D"_blank">patricer@gmail.com</a>&gt;=
</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">#1 is probably =
the most used in practice, to be honest. #4 is cool. The rest, not sure.<br=
></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><=
br><div class=3D"gmail_quote">2015-07-14 11:45 GMT-04:00 David Krauss <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:potswa@mac.com" target=3D"_blank">potswa=
@mac.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
&gt; On 2015=E2=80=9307=E2=80=9314, at 11:37 PM, Edward Catmur &lt;<a href=
=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.uk</a>&gt; wrote=
:<br>
&gt;<br>
&gt; Sorry for the confusion but, exactly which algorithm(s) are we discuss=
ing at present? I can think of several:<br>
&gt;<br>
&gt; 1. void unstable_erase(vector&amp;, It position);=C2=A0 // erase a sin=
gle element<br>
&gt; 2. void unstable_erase(vector&amp;, It start, It end);=C2=A0 // erase =
a range of elements<br>
&gt; 3. void unstable_erase(vector&amp;, T const&amp; value);=C2=A0 // eras=
e all elements having a particular value<br>
&gt; 4. void unstable_erase_if(vector&amp;, Predicate);=C2=A0 // erase all =
elements satisfying a predicate<br>
&gt; 5. It unstable_remove(It start, It end, T const&amp; value);=C2=A0 // =
remove all elements having a particular value<br>
&gt; 6. It unstable_remove_if(It start, It end, Predicate);=C2=A0 // remove=
 all elements satisfying a predicate<br>
&gt;<br>
&gt; It seems like the original proposal was for (1), possibly as a member =
function, but we appear to have moved on to discussing (6) - was that inten=
ded?<br>
<br>
</span>I didn=E2=80=99t see anything about #5 before Aymeric mentioned it, =
and I was already thinking of #6 so I chimed in.<br>
<br>
However, all the discussion of actual use cases seem to be talking about #4=
.. It looks to me like #1-3 are extraneous and #5-6 might be solutions in se=
arch of a problem.<br>
<div><div><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c353e88dac30051ad901a0--

.