Topic: Range erase for std::vector and other containers.


Author: martin.tillmann@gmail.com
Date: Thu, 3 Mar 2016 06:15:43 -0800 (PST)
Raw View
------=_Part_615_1349973339.1457014543098
Content-Type: multipart/alternative;
 boundary="----=_Part_616_604838608.1457014543098"

------=_Part_616_604838608.1457014543098
Content-Type: text/plain; charset=UTF-8

std::vector offers range insert with

template<class InputIt>
void insert(InputIt first, InputIt last);

but erase is restricted to ranges in the container itself.

Is a range based erase function for containers like std::vector feasible?

This would allow code like:

  vector<int> v = {1,2,3,4,5};
  vector<int> u = {2,3,4};

  v.erase(u.begin(), u.end());    // v = {1,5}

The idea is not limited to std::vector, in my experience it is most often
needed in std::set.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9a7a06c1-860e-44b1-a865-8467c39d7e91%40isocpp.org.

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

<div dir=3D"ltr"><span style=3D"font-family: courier new,monospace;">std::v=
ector </span>offers range insert with<br><br><span style=3D"font-family: co=
urier new,monospace;">template&lt;class InputIt&gt;<br>void insert(InputIt =
first, InputIt last);</span><br><br>but <span style=3D"font-family: courier=
 new,monospace;">erase </span>is restricted to ranges in the container itse=
lf.<br> <br>Is a range based <span style=3D"font-family: courier new,monosp=
ace;">erase </span>function for containers like <span style=3D"font-family:=
 courier new,monospace;">std::vector</span> feasible?<br> <br>This would al=
low code like:<br><br><span style=3D"font-family: courier new,monospace;">=
=C2=A0 vector&lt;int&gt; v =3D {1,2,3,4,5};<br>=C2=A0 vector&lt;int&gt; u =
=3D {2,3,4};<br>=C2=A0 <br>=C2=A0 v.erase(u.begin(), u.end());=C2=A0=C2=A0=
=C2=A0 // v =3D {1,5}</span><br><br>The idea is not limited to <span style=
=3D"font-family: courier new,monospace;">std::vector</span><span style=3D"f=
ont-family: arial,sans-serif;">, </span>in my experience it is most often n=
eeded in <span style=3D"font-family: courier new,monospace;">std::set</span=
>.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9a7a06c1-860e-44b1-a865-8467c39d7e91%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9a7a06c1-860e-44b1-a865-8467c39d7e91=
%40isocpp.org</a>.<br />

------=_Part_616_604838608.1457014543098--
------=_Part_615_1349973339.1457014543098--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 3 Mar 2016 06:35:05 -0800 (PST)
Raw View
------=_Part_4052_2067885500.1457015705340
Content-Type: multipart/alternative;
 boundary="----=_Part_4053_752348761.1457015705340"

------=_Part_4053_752348761.1457015705340
Content-Type: text/plain; charset=UTF-8

On Thursday, March 3, 2016 at 9:15:43 AM UTC-5, martin....@gmail.com wrote:
>
> std::vector offers range insert with
>
> template<class InputIt>
> void insert(InputIt first, InputIt last);
>
> but erase is restricted to ranges in the container itself.
>
> Is a range based erase function for containers like std::vector feasible?
>
> This would allow code like:
>
>   vector<int> v = {1,2,3,4,5};
>   vector<int> u = {2,3,4};
>
>   v.erase(u.begin(), u.end());    // v = {1,5}
>
> The idea is not limited to std::vector, in my experience it is most often
> needed in std::set.
>

That function is not like `insert` in any way, shape, or form. `insert`
simply copies data; this `erase` is based on performing *equality* tests on
the values. That's a lot more complex, requiring iterating over the entire
container several times, each time testing each value with items in the
given array.

Indeed, your idea only has merit for `set` (and its ilk), and that's only
because `std::remove_if` doesn't work with set, thus forcing you to write
your own function. Though such a function is pretty trivial: a loop over
the range of items to be removed, with a call to `erase` for each one.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/14be4dea-5645-4248-8eea-031151269ec4%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, March 3, 2016 at 9:15:43 AM UTC-5, martin....=
@gmail.com wrote:<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"><span style=3D"font-family:courier new,monospace">std::vector </span>of=
fers range insert with<br><br><span style=3D"font-family:courier new,monosp=
ace">template&lt;class InputIt&gt;<br>void insert(InputIt first, InputIt la=
st);</span><br><br>but <span style=3D"font-family:courier new,monospace">er=
ase </span>is restricted to ranges in the container itself.<br> <br>Is a ra=
nge based <span style=3D"font-family:courier new,monospace">erase </span>fu=
nction for containers like <span style=3D"font-family:courier new,monospace=
">std::vector</span> feasible?<br> <br>This would allow code like:<br><br><=
span style=3D"font-family:courier new,monospace">=C2=A0 vector&lt;int&gt; v=
 =3D {1,2,3,4,5};<br>=C2=A0 vector&lt;int&gt; u =3D {2,3,4};<br>=C2=A0 <br>=
=C2=A0 v.erase(u.begin(), u.end());=C2=A0=C2=A0=C2=A0 // v =3D {1,5}</span>=
<br><br>The idea is not limited to <span style=3D"font-family:courier new,m=
onospace">std::vector</span><span style=3D"font-family:arial,sans-serif">, =
</span>in my experience it is most often needed in <span style=3D"font-fami=
ly:courier new,monospace">std::set</span>.<br></div></blockquote><div><br>T=
hat function is not like `insert` in any way, shape, or form. `insert` simp=
ly copies data; this `erase` is based on performing <i>equality</i> tests o=
n the values. That&#39;s a lot more complex, requiring iterating over the e=
ntire container several times, each time testing each value with items in t=
he given array.<br><br>Indeed, your idea only has merit for `set` (and its =
ilk), and that&#39;s only because `std::remove_if` doesn&#39;t work with se=
t, thus forcing you to write your own function. Though such a function is p=
retty trivial: a loop over the range of items to be removed, with a call to=
 `erase` for each one.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/14be4dea-5645-4248-8eea-031151269ec4%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/14be4dea-5645-4248-8eea-031151269ec4=
%40isocpp.org</a>.<br />

------=_Part_4053_752348761.1457015705340--
------=_Part_4052_2067885500.1457015705340--

.


Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 3 Mar 2016 15:36:56 +0100
Raw View
2016-03-03 15:15 GMT+01:00  <martin.tillmann@gmail.com>:
> std::vector offers range insert with
>
> template<class InputIt>
> void insert(InputIt first, InputIt last);

Yes, because the vector that has this member provides the feature to
insert new elements into itself, therefore it requires a source to
copy from.

> but erase is restricted to ranges in the container itself.

Looks normal to me, because the operation affects the container itself.

> Is a range based erase function for containers like std::vector feasible?
>
> This would allow code like:
>
>   vector<int> v = {1,2,3,4,5};
>   vector<int> u = {2,3,4};
>
>   v.erase(u.begin(), u.end());    // v = {1,5}

I would find this very astonishing and confusing that an container
object v considers itself responsible to remove elements from another
container u.

- Daniel

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGNvRgAk_Ry_yNkCR7cVNFty1qta2Pv_OvMXK3VJ%3DhrbDWPZrA%40mail.gmail.com.

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 3 Mar 2016 06:41:43 -0800 (PST)
Raw View
------=_Part_488_741912754.1457016103648
Content-Type: multipart/alternative;
 boundary="----=_Part_489_167540454.1457016103648"

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

On Thursday, March 3, 2016 at 9:36:58 AM UTC-5, Daniel Kr=C3=BCgler wrote:
>
> 2016-03-03 15:15 GMT+01:00  <martin....@gmail.com <javascript:>>:=20
> > std::vector offers range insert with=20
> >=20
> > template<class InputIt>=20
> > void insert(InputIt first, InputIt last);=20
>
> Yes, because the vector that has this member provides the feature to=20
> insert new elements into itself, therefore it requires a source to=20
> copy from.=20
>
> > but erase is restricted to ranges in the container itself.=20
>
> Looks normal to me, because the operation affects the container itself.=
=20
>
> > Is a range based erase function for containers like std::vector=20
> feasible?=20
> >=20
> > This would allow code like:=20
> >=20
> >   vector<int> v =3D {1,2,3,4,5};=20
> >   vector<int> u =3D {2,3,4};=20
> >=20
> >   v.erase(u.begin(), u.end());    // v =3D {1,5}=20
>
> I would find this very astonishing and confusing that an container=20
> object v considers itself responsible to remove elements from another=20
> container u.=20
>

That's not what it's doing. It's *conditionally* erasing elements from `v`;=
=20
specifically, it's erasing any element that matches an element in the given=
=20
range. `u` is left unchanged.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5846f36a-8119-4ec0-b1bd-fcfe1bce27f7%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, March 3, 2016 at 9:36:58 AM UTC-5, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-03-03 15=
:15 GMT+01:00 =C2=A0&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"GamsuFbBBAAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&=
#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&=
#39;;return true;">martin....@gmail.com</a>&gt;:
<br>&gt; std::vector offers range insert with
<br>&gt;
<br>&gt; template&lt;class InputIt&gt;
<br>&gt; void insert(InputIt first, InputIt last);
<br>
<br>Yes, because the vector that has this member provides the feature to
<br>insert new elements into itself, therefore it requires a source to
<br>copy from.
<br>
<br>&gt; but erase is restricted to ranges in the container itself.
<br>
<br>Looks normal to me, because the operation affects the container itself.
<br>
<br>&gt; Is a range based erase function for containers like std::vector fe=
asible?
<br>&gt;
<br>&gt; This would allow code like:
<br>&gt;
<br>&gt; =C2=A0 vector&lt;int&gt; v =3D {1,2,3,4,5};
<br>&gt; =C2=A0 vector&lt;int&gt; u =3D {2,3,4};
<br>&gt;
<br>&gt; =C2=A0 v.erase(u.begin(), u.end()); =C2=A0 =C2=A0// v =3D {1,5}
<br>
<br>I would find this very astonishing and confusing that an container
<br>object v considers itself responsible to remove elements from another
<br>container u.
<br></blockquote><div><br>That&#39;s not what it&#39;s doing. It&#39;s <i>c=
onditionally</i> erasing elements from `v`; specifically, it&#39;s erasing =
any element that matches an element in the given range. `u` is left unchang=
ed.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5846f36a-8119-4ec0-b1bd-fcfe1bce27f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5846f36a-8119-4ec0-b1bd-fcfe1bce27f7=
%40isocpp.org</a>.<br />

------=_Part_489_167540454.1457016103648--
------=_Part_488_741912754.1457016103648--

.


Author: =?UTF-8?Q?Daniel_Kr=C3=BCgler?= <daniel.kruegler@gmail.com>
Date: Thu, 3 Mar 2016 15:47:29 +0100
Raw View
2016-03-03 15:41 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> On Thursday, March 3, 2016 at 9:36:58 AM UTC-5, Daniel Kr=C3=BCgler wrote=
:
>>
>> 2016-03-03 15:15 GMT+01:00  <martin....@gmail.com>:
>> > std::vector offers range insert with
>> >
>> > template<class InputIt>
>> > void insert(InputIt first, InputIt last);
>>
>> Yes, because the vector that has this member provides the feature to
>> insert new elements into itself, therefore it requires a source to
>> copy from.
>>
>> > but erase is restricted to ranges in the container itself.
>>
>> Looks normal to me, because the operation affects the container itself.
>>
>> > Is a range based erase function for containers like std::vector
>> > feasible?
>> >
>> > This would allow code like:
>> >
>> >   vector<int> v =3D {1,2,3,4,5};
>> >   vector<int> u =3D {2,3,4};
>> >
>> >   v.erase(u.begin(), u.end());    // v =3D {1,5}
>>
>> I would find this very astonishing and confusing that an container
>> object v considers itself responsible to remove elements from another
>> container u.
>
> That's not what it's doing. It's conditionally erasing elements from `v`;
> specifically, it's erasing any element that matches an element in the giv=
en
> range. `u` is left unchanged.

But that's how it looks like to me.

IMO erase with a predicate argument would look like a more general
solution for such a problem.

- Daniel

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAGNvRgA8fv%3DJg%2B4HtwFM6zSGLdzf4PSadz9Cr8_5Zoe=
my2FW2w%40mail.gmail.com.

.


Author: martin.tillmann@gmail.com
Date: Thu, 3 Mar 2016 06:57:55 -0800 (PST)
Raw View
------=_Part_526_264285643.1457017075131
Content-Type: multipart/alternative;
 boundary="----=_Part_527_1739972783.1457017075131"

------=_Part_527_1739972783.1457017075131
Content-Type: text/plain; charset=UTF-8


>
> That function is not like `insert` in any way, shape, or form. `insert`
> simply copies data; this `erase` is based on performing *equality* tests
> on the values. That's a lot more complex, requiring iterating over the
> entire container several times, each time testing each value with items in
> the given array.
>

Absolutely, to be honest I don't see this as a reason to omit this
functionality.


>
> Indeed, your idea only has merit for `set` (and its ilk), and that's only
> because `std::remove_if` doesn't work with set, thus forcing you to write
> your own function. Though such a function is pretty trivial: a loop over
> the range of items to be removed, with a call to `erase` for each one.
>

Agreed, but again this is not really an argument against such a function,
or is 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/266bcd23-1ef9-4c72-940d-641f6fb8cf1f%40isocpp.org.

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

<div dir=3D"ltr"><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"><div>That function is not like `insert` in any way, shape, or form. `in=
sert` simply copies data; this `erase` is based on performing <i>equality</=
i> tests on the values. That&#39;s a lot more complex, requiring iterating =
over the entire container several times, each time testing each value with =
items in the given array.<br></div></div></blockquote><div><br>Absolutely, =
to be honest I don&#39;t see this as a reason to omit this functionality.<b=
r>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><br>Indeed, your idea only has merit for `set` (and its ilk), and tha=
t&#39;s only because `std::remove_if` doesn&#39;t work with set, thus forci=
ng you to write your own function. Though such a function is pretty trivial=
: a loop over the range of items to be removed, with a call to `erase` for =
each one.<br></div></div></blockquote><div><br>Agreed, but again this is no=
t really an argument against such a function, or is it?<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/266bcd23-1ef9-4c72-940d-641f6fb8cf1f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/266bcd23-1ef9-4c72-940d-641f6fb8cf1f=
%40isocpp.org</a>.<br />

------=_Part_527_1739972783.1457017075131--
------=_Part_526_264285643.1457017075131--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 3 Mar 2016 07:01:17 -0800 (PST)
Raw View
------=_Part_896_135917391.1457017277703
Content-Type: multipart/alternative;
 boundary="----=_Part_897_1354436985.1457017277704"

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

On Thursday, March 3, 2016 at 9:47:31 AM UTC-5, Daniel Kr=C3=BCgler wrote:
>
> 2016-03-03 15:41 GMT+01:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:=
=20
> > On Thursday, March 3, 2016 at 9:36:58 AM UTC-5, Daniel Kr=C3=BCgler wro=
te:=20
> >>=20
> >> 2016-03-03 15:15 GMT+01:00  <martin....@gmail.com>:=20
> >> > std::vector offers range insert with=20
> >> >=20
> >> > template<class InputIt>=20
> >> > void insert(InputIt first, InputIt last);=20
> >>=20
> >> Yes, because the vector that has this member provides the feature to=
=20
> >> insert new elements into itself, therefore it requires a source to=20
> >> copy from.=20
> >>=20
> >> > but erase is restricted to ranges in the container itself.=20
> >>=20
> >> Looks normal to me, because the operation affects the container itself=
..=20
> >>=20
> >> > Is a range based erase function for containers like std::vector=20
> >> > feasible?=20
> >> >=20
> >> > This would allow code like:=20
> >> >=20
> >> >   vector<int> v =3D {1,2,3,4,5};=20
> >> >   vector<int> u =3D {2,3,4};=20
> >> >=20
> >> >   v.erase(u.begin(), u.end());    // v =3D {1,5}=20
> >>=20
> >> I would find this very astonishing and confusing that an container=20
> >> object v considers itself responsible to remove elements from another=
=20
> >> container u.=20
> >=20
> > That's not what it's doing. It's conditionally erasing elements from=20
> `v`;=20
> > specifically, it's erasing any element that matches an element in the=
=20
> given=20
> > range. `u` is left unchanged.=20
>
> But that's how it looks like to me.
>

I can't say that I would assume that this is what's going on. The code is=
=20
clearly calling a member function of `v`, so the natural assumption is that=
=20
the operation is mutating `v`.

But I do agree that the call doesn't look like what it's doing. There's no=
=20
reason to assume that `erase` would be doing a *search* of a `vector`,=20
particularly when you're passing a range of iterators (not to mention, this=
=20
conflicts with an existing overload). If such a call were truly needed, it=
=20
clearly needs its own *name*.

In any case, I'm sure that ranges, views, and adapters would make such a=20
function unnecessary.

--=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.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/024aea92-794f-435e-97a3-ad43dbc478bc%40isocpp.or=
g.

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

<div dir=3D"ltr">On Thursday, March 3, 2016 at 9:47:31 AM UTC-5, Daniel Kr=
=C3=BCgler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2016-03-03 15=
:41 GMT+01:00 Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"CfT1KurBBAAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;">jmck...@gmail.com</a>&gt;:
<br>&gt; On Thursday, March 3, 2016 at 9:36:58 AM UTC-5, Daniel Kr=C3=BCgle=
r wrote:
<br>&gt;&gt;
<br>&gt;&gt; 2016-03-03 15:15 GMT+01:00 =C2=A0&lt;<a>martin....@gmail.com</=
a>&gt;:
<br>&gt;&gt; &gt; std::vector offers range insert with
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; template&lt;class InputIt&gt;
<br>&gt;&gt; &gt; void insert(InputIt first, InputIt last);
<br>&gt;&gt;
<br>&gt;&gt; Yes, because the vector that has this member provides the feat=
ure to
<br>&gt;&gt; insert new elements into itself, therefore it requires a sourc=
e to
<br>&gt;&gt; copy from.
<br>&gt;&gt;
<br>&gt;&gt; &gt; but erase is restricted to ranges in the container itself=
..
<br>&gt;&gt;
<br>&gt;&gt; Looks normal to me, because the operation affects the containe=
r itself.
<br>&gt;&gt;
<br>&gt;&gt; &gt; Is a range based erase function for containers like std::=
vector
<br>&gt;&gt; &gt; feasible?
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; This would allow code like:
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; =C2=A0 vector&lt;int&gt; v =3D {1,2,3,4,5};
<br>&gt;&gt; &gt; =C2=A0 vector&lt;int&gt; u =3D {2,3,4};
<br>&gt;&gt; &gt;
<br>&gt;&gt; &gt; =C2=A0 v.erase(u.begin(), u.end()); =C2=A0 =C2=A0// v =3D=
 {1,5}
<br>&gt;&gt;
<br>&gt;&gt; I would find this very astonishing and confusing that an conta=
iner
<br>&gt;&gt; object v considers itself responsible to remove elements from =
another
<br>&gt;&gt; container u.
<br>&gt;
<br>&gt; That&#39;s not what it&#39;s doing. It&#39;s conditionally erasing=
 elements from `v`;
<br>&gt; specifically, it&#39;s erasing any element that matches an element=
 in the given
<br>&gt; range. `u` is left unchanged.
<br>
<br>But that&#39;s how it looks like to me.<br></blockquote><div><br>I can&=
#39;t say that I would assume that this is what&#39;s going on. The code is=
 clearly calling a member function of `v`, so the natural assumption is tha=
t the operation is mutating `v`.<br><br>But I do agree that the call doesn&=
#39;t look like what it&#39;s doing. There&#39;s no reason to assume that `=
erase` would be doing a <i>search</i> of a `vector`, particularly when you&=
#39;re passing a range of iterators (not to mention, this conflicts with an=
 existing overload). If such a call were truly needed, it clearly needs its=
 own <i>name</i>.<br><br>In any case, I&#39;m sure that ranges, views, and =
adapters would make such a function unnecessary.</div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/024aea92-794f-435e-97a3-ad43dbc478bc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/024aea92-794f-435e-97a3-ad43dbc478bc=
%40isocpp.org</a>.<br />

------=_Part_897_1354436985.1457017277704--
------=_Part_896_135917391.1457017277703--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 3 Mar 2016 07:08:24 -0800 (PST)
Raw View
------=_Part_7620_1819680190.1457017704539
Content-Type: multipart/alternative;
 boundary="----=_Part_7621_1741427073.1457017704540"

------=_Part_7621_1741427073.1457017704540
Content-Type: text/plain; charset=UTF-8

On Thursday, March 3, 2016 at 9:57:55 AM UTC-5, martin....@gmail.com wrote:
>
> That function is not like `insert` in any way, shape, or form. `insert`
>> simply copies data; this `erase` is based on performing *equality* tests
>> on the values. That's a lot more complex, requiring iterating over the
>> entire container several times, each time testing each value with items in
>> the given array.
>>
>
> Absolutely, to be honest I don't see this as a reason to omit this
> functionality.
>

It's an argument against your analogy with "insert". My point being that
your reasoning was poorly conceived.

Indeed, your idea only has merit for `set` (and its ilk), and that's only
>> because `std::remove_if` doesn't work with set, thus forcing you to write
>> your own function. Though such a function is pretty trivial: a loop over
>> the range of items to be removed, with a call to `erase` for each one.
>>
>
> Agreed, but again this is not really an argument against such a function,
> or is it?
>

It's an argument against making it a part of every container's interface.
It *might* be useful for certain specific cases, but your proposal was
stated to be universal.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/583032c6-e453-4c40-9075-435681c940ec%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, March 3, 2016 at 9:57:55 AM UTC-5, martin....=
@gmail.com wrote:<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"><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That func=
tion is not like `insert` in any way, shape, or form. `insert` simply copie=
s data; this `erase` is based on performing <i>equality</i> tests on the va=
lues. That&#39;s a lot more complex, requiring iterating over the entire co=
ntainer several times, each time testing each value with items in the given=
 array.<br></div></div></blockquote><div><br>Absolutely, to be honest I don=
&#39;t see this as a reason to omit this functionality.<br></div></div></bl=
ockquote><div><br>It&#39;s an argument against your analogy with &quot;inse=
rt&quot;. My point being that your reasoning was poorly conceived.<br><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Indeed, yo=
ur idea only has merit for `set` (and its ilk), and that&#39;s only because=
 `std::remove_if` doesn&#39;t work with set, thus forcing you to write your=
 own function. Though such a function is pretty trivial: a loop over the ra=
nge of items to be removed, with a call to `erase` for each one.<br></div><=
/div></blockquote><div><br>Agreed, but again this is not really an argument=
 against such a function, or is it?<br></div></div></blockquote><div><br>It=
&#39;s an argument against making it a part of every container&#39;s interf=
ace. It <i>might</i> be useful for certain specific cases, but your proposa=
l was stated to be universal.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/583032c6-e453-4c40-9075-435681c940ec%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/583032c6-e453-4c40-9075-435681c940ec=
%40isocpp.org</a>.<br />

------=_Part_7621_1741427073.1457017704540--
------=_Part_7620_1819680190.1457017704539--

.


Author: martin.tillmann@gmail.com
Date: Thu, 3 Mar 2016 07:10:36 -0800 (PST)
Raw View
------=_Part_215_1380948859.1457017836955
Content-Type: multipart/alternative;
 boundary="----=_Part_216_1872725034.1457017836955"

------=_Part_216_1872725034.1457017836955
Content-Type: text/plain; charset=UTF-8


>
> I can't say that I would assume that this is what's going on. The code is
> clearly calling a member function of `v`, so the natural assumption is that
> the operation is mutating `v`.
>

Yes. All values that appear in the given range (here u) are removed from v.


>
> But I do agree that the call doesn't look like what it's doing. There's no
> reason to assume that `erase` would be doing a *search* of a `vector`,
> particularly when you're passing a range of iterators (not to mention, this
> conflicts with an existing overload). If such a call were truly needed, it
> clearly needs its own *name*.
>

erase already performs this functionality for single elements and ranges of
the vector itself.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/73454c65-98c8-4327-a0f4-858652f5009e%40isocpp.org.

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

<div dir=3D"ltr"><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"><div>I can&#39;t say that I would assume that this is what&#39;s going =
on. The code is clearly calling a member function of `v`, so the natural as=
sumption is that the operation is mutating `v`.<br></div></div></blockquote=
><div><br>Yes. All values that appear in the given range (here <span style=
=3D"font-family: courier new,monospace;">u</span>) are removed from <span s=
tyle=3D"font-family: courier new,monospace;">v</span>.<br>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>But I do =
agree that the call doesn&#39;t look like what it&#39;s doing. There&#39;s =
no reason to assume that `erase` would be doing a <i>search</i> of a `vecto=
r`, particularly when you&#39;re passing a range of iterators (not to menti=
on, this conflicts with an existing overload). If such a call were truly ne=
eded, it clearly needs its own <i>name</i>.<br></div></div></blockquote><di=
v><br><span style=3D"font-family: courier new,monospace;">erase </span>alre=
ady performs this functionality for single elements and ranges of the vecto=
r itself. <br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/73454c65-98c8-4327-a0f4-858652f5009e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/73454c65-98c8-4327-a0f4-858652f5009e=
%40isocpp.org</a>.<br />

------=_Part_216_1872725034.1457017836955--
------=_Part_215_1380948859.1457017836955--

.


Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 3 Mar 2016 09:34:29 -0800 (PST)
Raw View
------=_Part_7833_1719804727.1457026469794
Content-Type: multipart/alternative;
 boundary="----=_Part_7834_1971349568.1457026469794"

------=_Part_7834_1971349568.1457026469794
Content-Type: text/plain; charset=UTF-8

On Thursday, March 3, 2016 at 10:10:37 AM UTC-5, martin....@gmail.com wrote:
>
> I can't say that I would assume that this is what's going on. The code is
>> clearly calling a member function of `v`, so the natural assumption is that
>> the operation is mutating `v`.
>>
>
> Yes. All values that appear in the given range (here u) are removed from v
> .
>
>
>>
>> But I do agree that the call doesn't look like what it's doing. There's
>> no reason to assume that `erase` would be doing a *search* of a
>> `vector`, particularly when you're passing a range of iterators (not to
>> mention, this conflicts with an existing overload). If such a call were
>> truly needed, it clearly needs its own *name*.
>>
>
> erase already performs this functionality for single elements and ranges
> of the vector itself.
>

No, it does not. `vector::erase` operates on *iterators*. Those iterators
represent the *positions within the vector* to erase. They do not represent
a range of *values* to compare elements of the vector against and
conditionally erase if they're equal. That is a completely different
operation.

And even if everything I said weren't true, you still cannot call it
`erase`. The reason being that `erase(iterator, iterator)` is a function
that already exists and has well-defined semantics. What you want would
require a change to the behavior of this function. At *best*, you would do
some kind of check to see if the range is within the container, and if it
isn't to do your special behavior. But that would have to be a *runtime*
check.

See, `vector<T>` places no requirements on `T` save being
MoveConstructible. And `vector<T>::erase` places no requirements that T
must be `EqualityComparable`. To implement the behavior you want,
`vector<T>::erase` would need to compare the value of Ts within the given
range, if the given range is outside the range of the container. But
because the range check would be a *runtime* check, `vector<T>::erase`
would require every T to be `EqualityComparable` *even if* you pass in a
range within the container to erase.

This would be a breaking change. So no, I don't think the committee will be
doing that. And even if you gave it a different name, I don't think the
committee will be doing it either; you can just use the erase/remove idiom
with a given lambda function. Or just make your own template function to do
the job.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b30464f1-3cee-4642-a699-4bf4f08e3386%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, March 3, 2016 at 10:10:37 AM UTC-5, martin...=
..@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><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>I can&#3=
9;t say that I would assume that this is what&#39;s going on. The code is c=
learly calling a member function of `v`, so the natural assumption is that =
the operation is mutating `v`.<br></div></div></blockquote><div><br>Yes. Al=
l values that appear in the given range (here <span style=3D"font-family:co=
urier new,monospace">u</span>) are removed from <span style=3D"font-family:=
courier new,monospace">v</span>.<br>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><br>But I do agree that the call doesn&#=
39;t look like what it&#39;s doing. There&#39;s no reason to assume that `e=
rase` would be doing a <i>search</i> of a `vector`, particularly when you&#=
39;re passing a range of iterators (not to mention, this conflicts with an =
existing overload). If such a call were truly needed, it clearly needs its =
own <i>name</i>.<br></div></div></blockquote><div><br><span style=3D"font-f=
amily:courier new,monospace">erase </span>already performs this functionali=
ty for single elements and ranges of the vector itself. <br></div></div></b=
lockquote><div><br>No, it does not. `vector::erase` operates on <i>iterator=
s</i>. Those iterators represent the <i>positions within the vector</i> to =
erase. They do not represent a range of <i>values</i> to compare elements o=
f the vector against and conditionally erase if they&#39;re equal. That is =
a completely different operation.<br><br>And even if everything I said were=
n&#39;t true, you still cannot call it `erase`. The reason being that `eras=
e(iterator, iterator)` is a function that already exists and has well-defin=
ed semantics. What you want would require a change to the behavior of this =
function. At <i>best</i>, you would do some kind of check to see if the ran=
ge is within the container, and if it isn&#39;t to do your special behavior=
.. But that would have to be a <i>runtime</i> check.<br><br>See, `vector&lt;=
T&gt;` places no requirements on `T` save being MoveConstructible. And `vec=
tor&lt;T&gt;::erase` places no requirements that T must be `EqualityCompara=
ble`. To implement the behavior you want, `vector&lt;T&gt;::erase` would ne=
ed to compare the value of Ts within the given range, if the given range is=
 outside the range of the container. But because the range check would be a=
 <i>runtime</i> check, `vector&lt;T&gt;::erase` would require every T to be=
 `EqualityComparable` <i>even if</i> you pass in a range within the contain=
er to erase.<br><br>This would be a breaking change. So no, I don&#39;t thi=
nk the committee will be doing that. And even if you gave it a different na=
me, I don&#39;t think the committee will be doing it either; you can just u=
se the erase/remove idiom with a given lambda function. Or just make your o=
wn template function to do the job.<br></div></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b30464f1-3cee-4642-a699-4bf4f08e3386%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b30464f1-3cee-4642-a699-4bf4f08e3386=
%40isocpp.org</a>.<br />

------=_Part_7834_1971349568.1457026469794--
------=_Part_7833_1719804727.1457026469794--

.


Author: martin.tillmann@gmail.com
Date: Thu, 3 Mar 2016 10:04:37 -0800 (PST)
Raw View
------=_Part_414_1944500003.1457028277700
Content-Type: multipart/alternative;
 boundary="----=_Part_415_592921341.1457028277700"

------=_Part_415_592921341.1457028277700
Content-Type: text/plain; charset=UTF-8

Thank you, this is a good explanation.

So in conculsion it is only feasible for mapped containers like std::set
and would need an new name to not collide with the sementics of the
existing range erase.
The existing methods like
for(auto& x : vector) set.erase(x);
or std::remove_if with a custom predicate seemed like something the library
could abstract from, especially since this is such a straight forward
use-case.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b2929634-db24-427d-8f54-8b8ff4b047ef%40isocpp.org.

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

<div dir=3D"ltr">Thank you, this is a good explanation.<br><br>So in concul=
sion it is only feasible for mapped containers like <span style=3D"font-fam=
ily: courier new,monospace;">std::set</span> and would need an new name to =
not collide with the sementics of the existing range <span style=3D"font-fa=
mily: courier new,monospace;">erase</span>.<br>The existing methods like<br=
><span style=3D"font-family: courier new,monospace;">for(auto&amp; x : vect=
or) set.erase(x);</span><br>or <span style=3D"font-family: courier new,mono=
space;">std::remove_if</span> with a custom predicate seemed like something=
 the library could abstract from, especially since this is such a straight =
forward use-case.<br></div>

<p></p>

-- <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b2929634-db24-427d-8f54-8b8ff4b047ef%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b2929634-db24-427d-8f54-8b8ff4b047ef=
%40isocpp.org</a>.<br />

------=_Part_415_592921341.1457028277700--
------=_Part_414_1944500003.1457028277700--

.