Topic: N4009: return type of erase_if
Author: jgottman6@gmail.com
Date: Sat, 24 May 2014 18:45:04 -0700 (PDT)
Raw View
------=_Part_1584_19118083.1400982304751
Content-Type: text/plain; charset=UTF-8
N4009 <https://isocpp.org/files/papers/n4009.txt> proposes a new template
function, erase_if, that takes a reference to container and a predicate as
parameters and erases every element of the container for which that
predicate is true. It is overloaded for each container type, so for
instance the vector version is
template <class T, class A, class Predicate>
void erase_if(vector<T, A>& c, Predicate pred);
I think this is a very good idea except for the return type of the
function. Often, when coders are erasing more than one element from a
container they need to know the number of elements that were erased. While
for std::vector it would be easy to compute this by saving the size before
the erasure and after the erase_if operator and subtracting, if a container
does not provide size() or has a linear-time size() function this isn't
that easy. Also, the version of container's erase() function that takes a
value returns the number of elements erased. Therefore, I think the
erase_if function should return the number of elements that were erased. It
can be declared as
template <class T, class A, class Predicate>
typename vector<T, A>::size_type erase_if(vector<T, A>& c, Predicate pred);
Joe Gottman
--
---
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_1584_19118083.1400982304751
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><a href=3D"https://isocpp.org/files/papers/n4009.txt">N400=
9</a> proposes a new template function, erase_if, that takes a reference to=
container and a predicate as parameters and erases every element of the co=
ntainer for which that predicate is true. It is overloaded for each contain=
er type, so for instance the vector version is<br><br><div class=3D"prettyp=
rint" 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"subprettyprint"><pre><span style=
=3D"color: #008;" class=3D"styled-by-prettify">template</span><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">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> A</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Predicate</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">></span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br> </span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> erase_if</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">vector</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> A</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">>&</span><span sty=
le=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"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Predicate</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> pred</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span></pre></div></code></div><br><br><br>I think th=
is is a very good idea except for the return type of the function. Of=
ten, when coders are erasing more than one element from a container they ne=
ed to know the number of elements that were erased. While for std::ve=
ctor it would be easy to compute this by saving the size before the erasure=
and after the erase_if operator and subtracting, if a container does not p=
rovide size() or has a linear-time size() function this isn't that easy. Al=
so, the version of container's erase() function that takes a value returns =
the number of elements erased. Therefore, I think the erase_if functi=
on should return the number of elements that were erased. It can be declare=
d as<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, =
250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wi=
dth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D=
"subprettyprint"><pre><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">template</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">class</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> A</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>class</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">Predicate</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> vector</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> A</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">>::</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">size_type </span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">erase_if</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> A</span><span style=3D"c=
olor: #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: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Predicate</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> pred</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span></pre></div></code></div><br><br><br>Joe Gottman<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" 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_1584_19118083.1400982304751--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 25 May 2014 12:25:17 +0800
Raw View
--Apple-Mail=_CB1DB7F7-A44D-484C-BD60-809E19CC704E
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-25, at 9:45 AM, jgottman6@gmail.com wrote:
> Therefore, I think the erase_if function should return the number of elements that were erased. It can be declared as
>
> template <class T, class A, class Predicate>
> typename vector<T, A>::size_type erase_if(vector<T, A>& c, Predicate pred);
Agreed. Also, I don't buy the proposal's reasons for being a (non-generic) non-member. It's making a lot of excuses not to simply apply list::remove_if to the other containers.
Considering list, why doesn't list::remove_if already return size_type?
--
---
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/.
--Apple-Mail=_CB1DB7F7-A44D-484C-BD60-809E19CC704E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05–25, at 9:45 AM, <a href=3D"mailto:jgottman6@gmail.com">jgott=
man6@gmail.com</a> wrote:</div><br class=3D"Apple-interchange-newline"><blo=
ckquote type=3D"cite"><div dir=3D"ltr">Therefore, I think the erase_if func=
tion should return the number of elements that were erased. It can be decla=
red as<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250=
, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word; p=
osition: static; z-index: auto;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><pre><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">template</span><span style=3D"" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=
=3D"" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">cla=
ss</span><span style=3D"" class=3D"styled-by-prettify"> A</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">class</span><span style=3D"" class=3D"styled-by-prettify">=
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Predicate=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></span=
><span style=3D"" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span style=
=3D"" class=3D"styled-by-prettify"> vector</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify"><</span><span style=3D"" class=3D"styled=
-by-prettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"" class=3D"styled-by-prettify"> A</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">>::</span><span style=
=3D"" class=3D"styled-by-prettify">size_type </span><span style=3D"" class=
=3D"styled-by-prettify">erase_if</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"" class=3D"styled-by-prettif=
y">vector</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"" class=3D"styled-by-prettify">T</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"" cla=
ss=3D"styled-by-prettify"> A</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">>&</span><span style=3D"" class=3D"styled-by-prett=
ify"> c</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</=
span><span style=3D"" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Predicate</span><span style=3D"" =
class=3D"styled-by-prettify"> pred</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">);</span></pre></div></code></div></div></blockquot=
e></div><br><div>Agreed. Also, I don’t buy the proposal’s reaso=
ns for being a (non-generic) non-member. It’s making a lot of excuses=
not to simply apply <font face=3D"Courier">list::remove_if</font>&nbs=
p;to the other containers.</div><div><br></div><div>Considering <font face=
=3D"Courier">list</font>, why doesn’t <font face=3D"Courier">list::re=
move_if</font> already return <font face=3D"Courier">size_type</font>?=
</div><div><br></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" 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=_CB1DB7F7-A44D-484C-BD60-809E19CC704E--
.
Author: Dain Bray <dain.bray@gmail.com>
Date: Sun, 25 May 2014 09:44:59 -0700 (PDT)
Raw View
------=_Part_1352_28028661.1401036299282
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Making it a non-member allows you to use type tags to implement it, instead=
=20
of re-implementing it for every container, so you really only need to=20
specialize for 1) containers that support erase(remove_if()) 2)=20
list/forward list 3) associative containers
I don't really care if it returns the # removed, but having implemented=20
this years ago in my own code base, I found 40 cases where I had used it,=
=20
and I don't recall ever wanting the # removed.
On Saturday, May 24, 2014 10:25:27 PM UTC-6, David Krauss wrote:
>
>
> On 2014=E2=80=9305=E2=80=9325, at 9:45 AM, jgot...@gmail.com <javascript:=
> wrote:
>
> Therefore, I think the erase_if function should return the number of=20
> elements that were erased. It can be declared as
>
> template <class T, class A, class Predicate>
> typename vector<T, A>::size_type erase_if(vector<T, A>& c, Predicate pre=
d);
>
>
> Agreed. Also, I don=E2=80=99t buy the proposal=E2=80=99s reasons for bein=
g a (non-generic)=20
> non-member. It=E2=80=99s making a lot of excuses not to simply apply=20
> list::remove_if to the other containers.
>
> Considering list, why doesn=E2=80=99t list::remove_if already return size=
_type?
>
>
--=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_1352_28028661.1401036299282
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Making it a non-member allows you to use type tags to impl=
ement it, instead of re-implementing it for every container, so you really =
only need to specialize for 1) containers that support erase(remove_if()) 2=
) list/forward list 3) associative containers<div><br></div><div> I do=
n't really care if it returns the # removed, but having implemented this ye=
ars ago in my own code base, I found 40 cases where I had used it, and I do=
n't recall ever wanting the # removed.<br><br>On Saturday, May 24, 2014 10:=
25:27 PM UTC-6, David Krauss wrote:<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:break-word"><br><div><div>On 2014=E2=80=9305=
=E2=80=9325, at 9:45 AM, <a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"yRbd65vHSBgJ" onmousedown=3D"this.href=3D'javascript:';ret=
urn true;" onclick=3D"this.href=3D'javascript:';return true;">jgot...@gmail=
..com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr">Therefo=
re, I think the erase_if function should return the number of elements that=
were erased. It can be declared as<br><br><div style=3D"background-color:r=
gb(250,250,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><co=
de><div><pre><span style=3D"color:#008">template</span><span> </span><span =
style=3D"color:#660"><</span><span style=3D"color:#008">class</span><spa=
n> T</span><span style=3D"color:#660">,</span><span> </span><span style=3D"=
color:#008">class</span><span> A</span><span style=3D"color:#660">,</span><=
span> </span><span style=3D"color:#008">class</span><span> </span><span sty=
le=3D"color:#606">Predicate</span><span style=3D"color:#660">></span><sp=
an><br> </span><span style=3D"color:#008">typename</span><span> vector=
</span><span style=3D"color:#660"><</span><span>T</span><span style=3D"c=
olor:#660">,</span><span> A</span><span style=3D"color:#660">>::</span><=
span>size_type </span><span>erase_if</span><span style=3D"color:#660">(</sp=
an><span>vector</span><span style=3D"color:#660"><</span><span>T</span><=
span style=3D"color:#660">,</span><span> A</span><span style=3D"color:#660"=
>>&</span><span> c</span><span style=3D"color:#660">,</span><span> <=
/span><span style=3D"color:#606">Predicate</span><span> pred</span><span st=
yle=3D"color:#660">);</span></pre></div></code></div></div></blockquote></d=
iv><br><div>Agreed. Also, I don=E2=80=99t buy the proposal=E2=80=99s reason=
s for being a (non-generic) non-member. It=E2=80=99s making a lot of excuse=
s not to simply apply <font face=3D"Courier">list::remove_if</font>&nb=
sp;to the other containers.</div><div><br></div><div>Considering <font face=
=3D"Courier">list</font>, why doesn=E2=80=99t <font face=3D"Courier">list::=
remove_if</font> already return <font face=3D"Courier">size_type</font=
>?</div><div><br></div></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" 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_1352_28028661.1401036299282--
.
Author: gmisocpp@gmail.com
Date: Mon, 26 May 2014 16:32:10 -0700 (PDT)
Raw View
------=_Part_3610_14538423.1401147130784
Content-Type: text/plain; charset=UTF-8
Hi
On Sunday, May 25, 2014 1:45:04 PM UTC+12, jgot...@gmail.com wrote:
> N4009 <https://isocpp.org/files/papers/n4009.txt> proposes a new template
> function, erase_if, that takes a reference to container and a predicate as
> parameters and erases every element of the container for which that
> predicate is true. It is overloaded for each container type, so for
> instance the vector version is
>
> template <class T, class A, class Predicate>
> void erase_if(vector<T, A>& c, Predicate pred);
>
>
>
>
> I think this is a very good idea except for the return type of the
> function. Often, when coders are erasing more than one element from a
> container they need to know the number of elements that were erased. While
> for std::vector it would be easy to compute this by saving the size before
> the erasure and after the erase_if operator and subtracting, if a container
> does not provide size() or has a linear-time size() function this isn't
> that easy. Also, the version of container's erase() function that takes a
> value returns the number of elements erased. Therefore, I think the
> erase_if function should return the number of elements that were erased. It
> can be declared as
>
> template <class T, class A, class Predicate>
> typename vector<T, A>::size_type erase_if(vector<T, A>& c, Predicate pred);
>
>
>
>
> Joe Gottman
>
>
I'm keen on N4009. I'm not strongly opposed to the return value being
changed, but I think void return is the right answer.
I say this because while I've found knowing a count of erased items
occasionally useful, I've mostly not needed it in my own code.
I also think if you want to know a count, you can supply a predicate that
does the counting. Right?
This would seem to be inline with the don't pay for what you don't use
principle.
I can also imagine (perhaps in a future stl) where you are erasing over
some kind of container that is stream like making the count logically
infinite. That's not a well thought out worry or probably relevant here;
but it might be something to think about in future designs.
If there is going to be a return value though, I'm not sure which is the
more useful return value to return: a count or what's been erased, or an
index to the position of the first erased item? Which is more useful? Or
perhaps a pair containing both values? This would not be valid for all
container types but it could be zero in that case I imagine.
Ultimately though I'm of the opinion the void return value is the right
answer, on the basis that if you want a count you can count it yourself
easy enough via the predicate and not forcing the algorithm to provide a
count might make the implementation easier and provide more optimisation
opportunities.
Thanks
--
---
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_3610_14538423.1401147130784
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hi</div><div><br>On Sunday, May 25, 2014 1:45:04 PM U=
TC+12, jgot...@gmail.com wrote:</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(2=
04, 204, 204); border-left-width: 1px; border-left-style: solid;"><div dir=
=3D"ltr"><a onmousedown=3D"this.href=3D'https://www.google.com/url?q\75http=
s%3A%2F%2Fisocpp.org%2Ffiles%2Fpapers%2Fn4009.txt\46sa\75D\46sntz\0751\46us=
g\75AFQjCNGcmx5hHXhFliyh_fC7E_P2tblQ1Q';return true;" onclick=3D"this.href=
=3D'https://www.google.com/url?q\75https%3A%2F%2Fisocpp.org%2Ffiles%2Fpaper=
s%2Fn4009.txt\46sa\75D\46sntz\0751\46usg\75AFQjCNGcmx5hHXhFliyh_fC7E_P2tblQ=
1Q';return true;" href=3D"https://isocpp.org/files/papers/n4009.txt" target=
=3D"_blank">N4009</a> proposes a new template function, erase_if, that take=
s a reference to container and a predicate as parameters and erases every e=
lement of the container for which that predicate is true. It is overloaded =
for each container type, so for instance the vector version is<br><br><div =
style=3D"border: 1px solid rgb(187, 187, 187); border-image: none; -ms-word=
-wrap: break-word; background-color: rgb(250, 250, 250);"><code><div><pre><=
span style=3D"color: rgb(0, 0, 136);">template</span><span style=3D"color: =
rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 102, 0);"><</span>=
<span style=3D"color: rgb(0, 0, 136);">class</span><span style=3D"color: rg=
b(0, 0, 0);"> T</span><span style=3D"color: rgb(102, 102, 0);">,</span><spa=
n style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 13=
6);">class</span><span style=3D"color: rgb(0, 0, 0);"> A</span><span style=
=3D"color: rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);">=
</span><span style=3D"color: rgb(0, 0, 136);">class</span><span style=3D"c=
olor: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 0, 102);">Predi=
cate</span><span style=3D"color: rgb(102, 102, 0);">></span><span style=
=3D"color: rgb(0, 0, 0);"><br> </span><span style=3D"color: rgb(0, 0,=
136);">void</span><span style=3D"color: rgb(0, 0, 0);"> erase_if</span><sp=
an style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, =
0, 0);">vector</span><span style=3D"color: rgb(102, 102, 0);"><</span><s=
pan style=3D"color: rgb(0, 0, 0);">T</span><span style=3D"color: rgb(102, 1=
02, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> A</span><span style=
=3D"color: rgb(102, 102, 0);">>&</span><span style=3D"color: rgb(0, =
0, 0);"> c</span><span style=3D"color: rgb(102, 102, 0);">,</span><span sty=
le=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 0, 102);=
">Predicate</span><span style=3D"color: rgb(0, 0, 0);"> pred</span><span st=
yle=3D"color: rgb(102, 102, 0);">);</span></pre></div></code></div><br><br>=
<br>I think this is a very good idea except for the return type of the func=
tion. Often, when coders are erasing more than one element from a con=
tainer they need to know the number of elements that were erased. Whi=
le for std::vector it would be easy to compute this by saving the size befo=
re the erasure and after the erase_if operator and subtracting, if a contai=
ner does not provide size() or has a linear-time size() function this isn't=
that easy. Also, the version of container's erase() function that takes a =
value returns the number of elements erased. Therefore, I think the e=
rase_if function should return the number of elements that were erased. It =
can be declared as<br><br><div style=3D"border: 1px solid rgb(187, 187, 187=
); border-image: none; -ms-word-wrap: break-word; background-color: rgb(250=
, 250, 250);"><code><div><pre><span style=3D"color: rgb(0, 0, 136);">templa=
te</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color:=
rgb(102, 102, 0);"><</span><span style=3D"color: rgb(0, 0, 136);">class=
</span><span style=3D"color: rgb(0, 0, 0);"> T</span><span style=3D"color: =
rgb(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> </span><sp=
an style=3D"color: rgb(0, 0, 136);">class</span><span style=3D"color: rgb(0=
, 0, 0);"> A</span><span style=3D"color: rgb(102, 102, 0);">,</span><span s=
tyle=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(0, 0, 136);=
">class</span><span style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"c=
olor: rgb(102, 0, 102);">Predicate</span><span style=3D"color: rgb(102, 102=
, 0);">></span><span style=3D"color: rgb(0, 0, 0);"><br> </span><sp=
an style=3D"color: rgb(0, 0, 136);">typename</span><span style=3D"color: rg=
b(0, 0, 0);"> vector</span><span style=3D"color: rgb(102, 102, 0);"><</s=
pan><span style=3D"color: rgb(0, 0, 0);">T</span><span style=3D"color: rgb(=
102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> A</span><span =
style=3D"color: rgb(102, 102, 0);">>::</span><span style=3D"color: rgb(0=
, 0, 0);">size_type </span><span style=3D"color: rgb(0, 0, 0);">erase_if</s=
pan><span style=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: =
rgb(0, 0, 0);">vector</span><span style=3D"color: rgb(102, 102, 0);"><</=
span><span style=3D"color: rgb(0, 0, 0);">T</span><span style=3D"color: rgb=
(102, 102, 0);">,</span><span style=3D"color: rgb(0, 0, 0);"> A</span><span=
style=3D"color: rgb(102, 102, 0);">>&</span><span style=3D"color: r=
gb(0, 0, 0);"> c</span><span style=3D"color: rgb(102, 102, 0);">,</span><sp=
an style=3D"color: rgb(0, 0, 0);"> </span><span style=3D"color: rgb(102, 0,=
102);">Predicate</span><span style=3D"color: rgb(0, 0, 0);"> pred</span><s=
pan style=3D"color: rgb(102, 102, 0);">);</span></pre></div></code></div><b=
r><br><br>Joe Gottman<br><br></div></blockquote><div><br></div><div><div>I'=
m keen on N4009. I'm not strongly opposed to the return value being c=
hanged, but I think void return is the right answer.<br></div><di=
v>I say this because while I've found knowing a count of era=
sed items occasionally useful, I've mostly not needed it in my ow=
n code.</div><div><br></div><div>I also think if you want to know a co=
unt, you can supply a predicate that does the counting. Right?</div><div>Th=
is would seem to be inline with the don't pay for what you don't use princi=
ple.</div><div><br></div><div>I can also imagine (perhaps in a fu=
ture stl) where you are erasing over some kind of container that is stream =
like making the count logically infinite. That's not a well =
thought out worry or probably relevant here; but it might be some=
thing to think about in future designs.</div><div><br></div><div>If there i=
s going to be a return value though, I'm not sure which is the more us=
eful return value to return: a count or what's been erased, =
or an index to the position of the first erased item? Which is more useful?=
Or perhaps a pair containing both values? This would not be valid for all =
container types but it could be zero in that case I imagine.</div><div=
><br></div><div>Ultimately though I'm of the opinion the void return value =
is the right answer, on the basis that if you want a count you can cou=
nt it yourself easy enough via the predicate and not forcing the algorithm =
to provide a count might make the implementation easier and provide more op=
timisation opportunities.</div><div><br></div><div>Thanks<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" 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_3610_14538423.1401147130784--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 27 May 2014 08:09:26 +0800
Raw View
--Apple-Mail=_E09590D8-F370-4E58-8F97-96431DA35714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-26, at 12:44 AM, Dain Bray <dain.bray@gmail.com> wrote:
> Making it a non-member allows you to use type tags to implement it, inste=
ad of re-implementing it for every container, so you really only need to sp=
ecialize for 1) containers that support erase(remove_if()) 2) list/forward =
list 3) associative containers
list and forward_list need separate implementations using splice and splice=
_after, respectively.
Users wouldn't get to use those tags, and so need to reimplement it for the=
ir own containers. The standard library could use a CRTP base to write the =
member function generically, or let the members simply dispatch to a generi=
c non-member. (This is arguably simpler than tag dispatching.) Library deta=
ils shouldn't be an interface consideration; by generic I meant for user-de=
fined containers.
> I don't really care if it returns the # removed, but having implemented t=
his years ago in my own code base, I found 40 cases where I had used it, an=
d I don't recall ever wanting the # removed.
I don't think this should be a vote. Sometimes you need to strictly account=
for the size of a set which is not stored in a container. If the result is=
discarded, the compiler will be able to elide its computation after inlini=
ng. Seldom does an increment instruction impact performance anyway. There's=
really no trade-off.
--=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=_E09590D8-F370-4E58-8F97-96431DA35714
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05–26, at 12:44 AM, Dain Bray <<a href=3D"mailto:dain.bray@g=
mail.com">dain.bray@gmail.com</a>> wrote:</div><br class=3D"Apple-interc=
hange-newline"><blockquote type=3D"cite"><div style=3D"font-family: Helveti=
ca; font-size: 12px; font-style: normal; font-variant: normal; font-weight:=
normal; letter-spacing: normal; line-height: normal; orphans: auto; text-a=
lign: start; text-indent: 0px; text-transform: none; white-space: normal; w=
idows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=
=3D"ltr">Making it a non-member allows you to use type tags to implement it=
, instead of re-implementing it for every container, so you really only nee=
d to specialize for 1) containers that support erase(remove_if()) 2) list/f=
orward list 3) associative containers</div></div></blockquote><div><br></di=
v><div><font face=3D"Courier">list</font> and <font face=3D"Courier">forwar=
d_list</font> need separate implementations using <font face=3D"Courier">sp=
lice</font> and <font face=3D"Courier">splice_after</font>, respectively.</=
div><div><br></div><div>Users wouldn’t get to use those tags, and so =
need to reimplement it for their own containers. The standard library could=
use a CRTP base to write the member function generically, or let the membe=
rs simply dispatch to a generic non-member. (This is arguably simpler than =
tag dispatching.) Library details shouldn’t be an interface considera=
tion; by generic I meant for user-defined containers.</div><div><br></div><=
blockquote type=3D"cite"><div style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px;"><div dir=3D"ltr"><div>I do=
n't really care if it returns the # removed, but having implemented this ye=
ars ago in my own code base, I found 40 cases where I had used it, and I do=
n't recall ever wanting the # removed.</div></div></div></blockquote><div><=
br></div><div>I don’t think this should be a vote. Sometimes you need=
to strictly account for the size of a set which is not stored in a contain=
er. If the result is discarded, the compiler will be able to elide its comp=
utation after inlining. Seldom does an increment instruction impact perform=
ance anyway. There’s really no trade-off.</div></div><br></body></htm=
l>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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=_E09590D8-F370-4E58-8F97-96431DA35714--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Tue, 27 May 2014 08:35:21 +0200
Raw View
On Mon, May 26, 2014 at 04:32:10PM -0700, gmisocpp@gmail.com wrote:
> Hi
>
> On Sunday, May 25, 2014 1:45:04 PM UTC+12, jgot...@gmail.com wrote:
>
> > N4009 <https://isocpp.org/files/papers/n4009.txt> proposes a new template
> > function, erase_if, that takes a reference to container and a predicate as
> > parameters and erases every element of the container for which that
> > predicate is true. It is overloaded for each container type, so for
> > instance the vector version is
> >
> > template <class T, class A, class Predicate>
> > void erase_if(vector<T, A>& c, Predicate pred);
> >
> >
> >
> >
> > I think this is a very good idea except for the return type of the
> > function. Often, when coders are erasing more than one element from a
> > container they need to know the number of elements that were erased. While
> > for std::vector it would be easy to compute this by saving the size before
> > the erasure and after the erase_if operator and subtracting, if a container
> > does not provide size() or has a linear-time size() function this isn't
> > that easy. Also, the version of container's erase() function that takes a
> > value returns the number of elements erased. Therefore, I think the
> > erase_if function should return the number of elements that were erased. It
> > can be declared as
> >
> > template <class T, class A, class Predicate>
> > typename vector<T, A>::size_type erase_if(vector<T, A>& c, Predicate pred);
> >
> >
> >
> >
> > Joe Gottman
> >
> >
> I'm keen on N4009. I'm not strongly opposed to the return value being
> changed, but I think void return is the right answer.
> I say this because while I've found knowing a count of erased items
> occasionally useful, I've mostly not needed it in my own code.
>
> I also think if you want to know a count, you can supply a predicate that
> does the counting. Right?
> This would seem to be inline with the don't pay for what you don't use
> principle.
>
> I can also imagine (perhaps in a future stl) where you are erasing over
> some kind of container that is stream like making the count logically
> infinite. That's not a well thought out worry or probably relevant here;
> but it might be something to think about in future designs.
>
> If there is going to be a return value though, I'm not sure which is the
> more useful return value to return: a count or what's been erased, or an
> index to the position of the first erased item? Which is more useful? Or
> perhaps a pair containing both values? This would not be valid for all
> container types but it could be zero in that case I imagine.
>
> Ultimately though I'm of the opinion the void return value is the right
> answer, on the basis that if you want a count you can count it yourself
> easy enough via the predicate and not forcing the algorithm to provide a
> count might make the implementation easier and provide more optimisation
> opportunities.
If the predicate is supposed to do any processing then I think the right
return value might be the predicate, similarly to for_each.
This should also work well together with the proxy support from N4035.
/MF
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 27 May 2014 15:22:49 +0800
Raw View
--Apple-Mail=_98A3DAFE-F9F0-4642-AEBA-0CFA5132C46D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-27, at 2:35 PM, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> If the predicate is supposed to do any processing then I think the right
> return value might be the predicate, similarly to for_each.
Ideally the user won't be writing their own predicate, and even if they do,=
it's easier to have it write to a reference to a variable, than to give it=
a member getter function. I don't think many folks ever availed of for_eac=
h like that, and these days most predicates are lambdas.
Optimization is easy with a local variable that is modified in a loop and t=
hen perhaps left unused. It gets harder when that variable is a member of a=
predicate object, or accessed by it through a reference. Returning size_ty=
pe provides the available information at essentially no cost. Not returning=
size_type makes the one-size-fits-all solution impossible, for no real ben=
efit.
> This should also work well together with the proxy support from N4035.
I don't see the connection. A predicate should not be used as a proxy for a=
side-effect result, and changing operator size_type() to operator auto() w=
ould only be even more obscure.
--=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=_98A3DAFE-F9F0-4642-AEBA-0CFA5132C46D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05–27, at 2:35 PM, Magnus Fromreide <<a href=3D"mailto:magfr=
@lysator.liu.se">magfr@lysator.liu.se</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite">If the predicate is suppos=
ed to do any processing then I think the right<br>return value might be the=
predicate, similarly to for_each.<br></blockquote><div><br></div><div>Idea=
lly the user won’t be writing their own predicate, and even if they d=
o, it’s easier to have it write to a reference to a variable, than to=
give it a member getter function. I don’t think many folks ever avai=
led of for_each like that, and these days most predicates are lambdas.</div=
><div><br></div><div>Optimization is easy with a local variable that is mod=
ified in a loop and then perhaps left unused. It gets harder when that vari=
able is a member of a predicate object, or accessed by it through a referen=
ce. Returning <font face=3D"Courier">size_type</font> provides the ava=
ilable information at essentially no cost. Not returning <font face=3D"Cour=
ier">size_type</font> makes the one-size-fits-all solution impossible, for =
no real benefit.</div><br><blockquote type=3D"cite">This should also work w=
ell together with the proxy support from N4035.<br></blockquote><div><br></=
div>I don’t see the connection. A predicate should not be used as a p=
roxy for a side-effect result, and changing <font face=3D"Courier">operator=
size_type()</font> to <font face=3D"Courier">operator auto()</font> would =
only be even more obscure.</div><div><br></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" 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=_98A3DAFE-F9F0-4642-AEBA-0CFA5132C46D--
.
Author: vadim.petrochenkov@gmail.com
Date: Tue, 27 May 2014 04:14:14 -0700 (PDT)
Raw View
------=_Part_256_4180133.1401189254922
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I'm curious, is there any general policy in the library on changing or not=
=20
changing "return void" to something in any way useful?
Because assuming the statement
> If the result is discarded, the compiler will be able to elide its=20
> computation after inlining.
is true, a lot of member functions, for example, could potentially benefit=
=20
from returning *this instead of void, but they still return void for some=
=20
reason.
On Tuesday, May 27, 2014 4:09:33 AM UTC+4, David Krauss wrote:
>
>
> On 2014=E2=80=9305=E2=80=9326, at 12:44 AM, Dain Bray <dain...@gmail.com =
<javascript:>>=20
> wrote:
>
> Making it a non-member allows you to use type tags to implement it,=20
> instead of re-implementing it for every container, so you really only nee=
d=20
> to specialize for 1) containers that support erase(remove_if()) 2)=20
> list/forward list 3) associative containers
>
>
> list and forward_list need separate implementations using splice and=20
> splice_after, respectively.
>
> Users wouldn=E2=80=99t get to use those tags, and so need to reimplement =
it for=20
> their own containers. The standard library could use a CRTP base to write=
=20
> the member function generically, or let the members simply dispatch to a=
=20
> generic non-member. (This is arguably simpler than tag dispatching.)=20
> Library details shouldn=E2=80=99t be an interface consideration; by gener=
ic I meant=20
> for user-defined containers.
>
> I don't really care if it returns the # removed, but having implemented=
=20
> this years ago in my own code base, I found 40 cases where I had used it,=
=20
> and I don't recall ever wanting the # removed.
>
>
> I don=E2=80=99t think this should be a vote. Sometimes you need to strict=
ly=20
> account for the size of a set which is not stored in a container. If the=
=20
> result is discarded, the compiler will be able to elide its computation=
=20
> after inlining. Seldom does an increment instruction impact performance=
=20
> anyway. There=E2=80=99s really no trade-off.
>
>
--=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_256_4180133.1401189254922
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm curious, is there any general policy in the library on=
changing or not changing "return void" to something in any way u=
seful?<br><br>Because assuming the statement<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=
;">If the result is discarded, the compiler will be able to elide its compu=
tation after inlining.</blockquote><div>is true, a lot of member functions,=
for example, could potentially benefit from returning *this instead of voi=
d, but they still return void for some reason.</div><br>On Tuesday, May 27,=
2014 4:09:33 AM UTC+4, David Krauss wrote:<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:break-word"><br><div><div>On 2014=E2=
=80=9305=E2=80=9326, at 12:44 AM, Dain Bray <<a href=3D"javascript:" tar=
get=3D"_blank" gdf-obfuscated-mailto=3D"FIeIh7vZD2YJ" onmousedown=3D"this.h=
ref=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';retu=
rn true;">dain...@gmail.com</a>> wrote:</div><br><blockquote type=3D"cit=
e"><div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;fon=
t-variant:normal;font-weight:normal;letter-spacing:normal;line-height:norma=
l;text-align:start;text-indent:0px;text-transform:none;white-space:normal;w=
ord-spacing:0px"><div dir=3D"ltr">Making it a non-member allows you to use =
type tags to implement it, instead of re-implementing it for every containe=
r, so you really only need to specialize for 1) containers that support era=
se(remove_if()) 2) list/forward list 3) associative containers</div></div><=
/blockquote><div><br></div><div><font face=3D"Courier">list</font> and <fon=
t face=3D"Courier">forward_list</font> need separate implementations using =
<font face=3D"Courier">splice</font> and <font face=3D"Courier">splice_afte=
r</font>, respectively.</div><div><br></div><div>Users wouldn=E2=80=99t get=
to use those tags, and so need to reimplement it for their own containers.=
The standard library could use a CRTP base to write the member function ge=
nerically, or let the members simply dispatch to a generic non-member. (Thi=
s is arguably simpler than tag dispatching.) Library details shouldn=E2=80=
=99t be an interface consideration; by generic I meant for user-defined con=
tainers.</div><div><br></div><blockquote type=3D"cite"><div style=3D"font-f=
amily:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-w=
eight:normal;letter-spacing:normal;line-height:normal;text-align:start;text=
-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div d=
ir=3D"ltr"><div>I don't really care if it returns the # removed, but having=
implemented this years ago in my own code base, I found 40 cases where I h=
ad used it, and I don't recall ever wanting the # removed.</div></div></div=
></blockquote><div><br></div><div>I don=E2=80=99t think this should be a vo=
te. Sometimes you need to strictly account for the size of a set which is n=
ot stored in a container. If the result is discarded, the compiler will be =
able to elide its computation after inlining. Seldom does an increment inst=
ruction impact performance anyway. There=E2=80=99s really no trade-off.</di=
v></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" 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_256_4180133.1401189254922--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 27 May 2014 20:45:39 +0800
Raw View
--Apple-Mail=_F934CA55-E327-471A-AAD4-9F22DEE20708
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-27, at 7:14 PM, vadim.petrochenkov@gmail.com wrote:
> I'm curious, is there any general policy in the library on changing or no=
t changing "return void" to something in any way useful?
>=20
> Because assuming the statement
> If the result is discarded, the compiler will be able to elide its comput=
ation after inlining.
> is true, a lot of member functions, for example, could potentially benefi=
t from returning *this instead of void, but they still return void for some=
reason.
Returning this (or *this) is of no help to the CPU, which already has acces=
s to the value from wherever it got it prior to the call.
Some ABIs (well, at least one, for Windows x86 if I recall correctly) retur=
n this from constructors, so as to relieve register pressure, but that's a =
special case of integration between the optimizer and the ABI.
Anyway, I'm unclear on the connection with my statement. Optimizers can per=
form lifetime analysis on local variables, but variables accessed through p=
ointers or references are trickier. Inlining a function may allow its local=
variables to become locals in the calling function, and then lifetime anal=
ysis may discover that the "number erased" result is never used aside from =
increment instructions. If all this works correctly, which is reasonable to=
suppose but far from a sure thing, then counting but ignoring the number o=
f erased elements is free. That's all I'm saying.
--=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=_F934CA55-E327-471A-AAD4-9F22DEE20708
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html cha=
rset=3Dwindows-1252"><meta http-equiv=3D"Content-Type" content=3D"text/html=
charset=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webk=
it-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>=
On 2014–05–27, at 7:14 PM, <a href=3D"mailto:vadim.petrochenkov=
@gmail.com">vadim.petrochenkov@gmail.com</a> wrote:</div><br class=3D"Apple=
-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I'm curiou=
s, is there any general policy in the library on changing or not changing "=
return void" to something in any way useful?<br><br>Because assum=
ing the statement<div><blockquote class=3D"gmail_quote" style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 2=
04); border-left-style: solid; padding-left: 1ex;">If the result is discard=
ed, the compiler will be able to elide its computation after inlining.</blo=
ckquote><div>is true, a lot of member functions, for example, could potenti=
ally benefit from returning *this instead of void, but they still return vo=
id for some reason.</div></div></div></blockquote><div><br></div><div>Retur=
ning this (or *this) is of no help to the CPU, which already has access to =
the value from wherever it got it prior to the call.</div></div><br><div>So=
me ABIs (well, at least one, for Windows x86 if I recall correctly) return =
this from constructors, so as to relieve register pressure, but that’=
s a special case of integration between the optimizer and the ABI.</div><di=
v><br></div><div>Anyway, I’m unclear on the connection with my statem=
ent. Optimizers can perform lifetime analysis on local variables, but varia=
bles accessed through pointers or references are trickier. Inlining a funct=
ion may allow its local variables to become locals in the calling function,=
and then lifetime analysis may discover that the “number erased&rdqu=
o; result is never used aside from increment instructions. If all this work=
s correctly, which is reasonable to suppose but far from a sure thing, then=
counting but ignoring the number of erased elements is free. That’s =
all I’m saying.</div><div><br></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" 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=_F934CA55-E327-471A-AAD4-9F22DEE20708--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Tue, 27 May 2014 12:44:32 -0400
Raw View
On 2014-05-27 08:45, David Krauss wrote:
> On 2014-05-27, at 7:14 PM, vadim.petrochenkov@gmail.com wrote:
>> I'm curious, is there any general policy in the library on changing
>> or not changing "return void" to something in any way useful?
>>
>> Because assuming the statement If the result is discarded, the
>> compiler will be able to elide its computation after inlining. is
>> true, a lot of member functions, for example, could potentially
>> benefit from returning *this instead of void, but they still return
>> void for some reason.
>
> Returning this (or *this) is of no help to the CPU, which already has
> access to the value from wherever it got it prior to the call.
I suspect the benefit here isn't optimization, but rather code writing,
e.g. to be able to write:
std::vector<int> v;
v.clear().push_back(2).insert(v.begin(), 1); // etc.
(Not the best example, but hopefully you get the idea.)
--
Matthew
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Wed, 28 May 2014 10:17:19 +0800
Raw View
On 2014-05-28, at 12:44 AM, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> On 2014-05-27 08:45, David Krauss wrote:
>> On 2014-05-27, at 7:14 PM, vadim.petrochenkov@gmail.com wrote:
>>> I'm curious, is there any general policy in the library on changing
>>> or not changing "return void" to something in any way useful?
>>>
>>> Because assuming the statement If the result is discarded, the
>>> compiler will be able to elide its computation after inlining. is
>>> true, a lot of member functions, for example, could potentially
>>> benefit from returning *this instead of void, but they still return
>>> void for some reason.
>>
>> Returning this (or *this) is of no help to the CPU, which already has
>> access to the value from wherever it got it prior to the call.
>
> I suspect the benefit here isn't optimization, but rather code writing,
> e.g. to be able to write:
There was probably some misunderstanding about what I meant by "elide computation."
> std::vector<int> v;
> v.clear().push_back(2).insert(v.begin(), 1); // etc.
>
> (Not the best example, but hopefully you get the idea.)
As good an example as any. That's not the direction of C++. A carriage return and a variable declaration never killed anyone.
--
---
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/.
.
Author: jgottman6@gmail.com
Date: Tue, 27 May 2014 19:54:00 -0700 (PDT)
Raw View
------=_Part_1695_26870976.1401245640914
Content-Type: text/plain; charset=UTF-8
On Tuesday, May 27, 2014 12:44:50 PM UTC-4, Matthew Woehlke wrote:
>
>
> I suspect the benefit here isn't optimization, but rather code writing,
> e.g. to be able to write:
>
> std::vector<int> v;
> v.clear().push_back(2).insert(v.begin(), 1); // etc.
>
> (Not the best example, but hopefully you get the idea.)
>
>
I get the idea, and this example accidentally shows why this is not a good
idea. The v.begin() passed to the insert() function might be the value of
begin() at the beginning of the statement. If the push_back() allocated
memory (i.e. if v started with capacity() == 0), then that iterator will
be invalidated before the insert can be done, resulting in undefined
behavior.
--
---
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_1695_26870976.1401245640914
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Tuesday, May 27, 2014 12:44:50 PM UTC-4, Matthe=
w Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>I suspect =
the benefit here isn't optimization, but rather code writing,
<br>e.g. to be able to write:
<br>
<br> std::vector<int> v;
<br> v.clear().push_back(2).insert(<wbr>v.begin(), 1); // etc.
<br>
<br>(Not the best example, but hopefully you get the idea.)
<br>
<br></blockquote><div><br><br>I get the idea, and this example accidentally=
shows why this is not a good idea. The v.begin() passed to the inser=
t() function might be the value of begin() at the beginning of the statemen=
t. If the push_back() allocated memory (i.e. if v started with capaci=
ty() =3D=3D 0), then that iterator will be invalidated before the ins=
ert can be done, resulting in undefined behavior. <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" 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_1695_26870976.1401245640914--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Wed, 28 May 2014 11:28:20 -0400
Raw View
On 2014-05-27 22:54, jgottman6@gmail.com wrote:
> On Tuesday, May 27, 2014 12:44:50 PM UTC-4, Matthew Woehlke wrote:
>> I suspect the benefit here isn't optimization, but rather code writing,
>> e.g. to be able to write:
>>
>> std::vector<int> v;
>> v.clear().push_back(2).insert(v.begin(), 1); // etc.
>>
>> (Not the best example, but hopefully you get the idea.)
>
> I get the idea, and this example accidentally shows why this is not a good
> idea. The v.begin() passed to the insert() function might be the value of
> begin() at the beginning of the statement. If the push_back() allocated
> memory (i.e. if v started with capacity() == 0), then that iterator will
> be invalidated before the insert can be done, resulting in undefined
> behavior.
(Getting way OT...) If that's actually possible I'd be inclined to call
it a bug in the language. I'm having a hard time imagining under what
circumstances it's desirable to evaluate the arguments for a method
invocation before you are able to know what object the method will be
invoked against.
Of course, you could always write instead:
v.insert(v.clear().push_back(2).begin(), 1);
....but that's just getting really ugly.
There are probably better examples of methods that return void that
could return themselves where call chaining would be more useful /
intuitive and less error prone, but I agree that going crazy with it is
probably not good.
--
Matthew
--
---
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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 29 May 2014 08:13:35 +0800
Raw View
--Apple-Mail=_F26B8504-9764-4A91-9D41-BFDFD2DB1590
Content-Type: text/plain; charset=ISO-8859-1
On 2014-05-28, at 11:28 PM, Matthew Woehlke <mw_triad@users.sourceforge.net> wrote:
> On 2014-05-27 22:54, jgottman6@gmail.com wrote:
>> On Tuesday, May 27, 2014 12:44:50 PM UTC-4, Matthew Woehlke wrote:
>>> I suspect the benefit here isn't optimization, but rather code writing,
>>> e.g. to be able to write:
>>>
>>> std::vector<int> v;
>>> v.clear().push_back(2).insert(v.begin(), 1); // etc.
>>>
>>> (Not the best example, but hopefully you get the idea.)
>>
>> I get the idea, and this example accidentally shows why this is not a good
>> idea. The v.begin() passed to the insert() function might be the value of
>> begin() at the beginning of the statement. If the push_back() allocated
>> memory (i.e. if v started with capacity() == 0), then that iterator will
>> be invalidated before the insert can be done, resulting in undefined
>> behavior.
>
> (Getting way OT...) If that's actually possible I'd be inclined to call
> it a bug in the language.
The real bug is that we don't have a way to explicitly express such ambiguity without putting things all on one line.
If you want subexpressions to be evaluated in deterministic order, then write in Java.
> I'm having a hard time imagining under what
> circumstances it's desirable to evaluate the arguments for a method
> invocation before you are able to know what object the method will be
> invoked against.
You (the programmer) are responsible for making order of evaluation inconsequential. The compiler should be free to schedule things for the convenience of the CPU.
--
---
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/.
--Apple-Mail=_F26B8504-9764-4A91-9D41-BFDFD2DB1590
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;05–28, at 11:28 PM, Matthew Woehlke <<a href=3D"mailto:mw_tr=
iad@users.sourceforge.net">mw_triad@users.sourceforge.net</a>> wrote:</d=
iv><br class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><div s=
tyle=3D"font-size: 12px; font-style: normal; font-variant: normal; font-wei=
ght: normal; letter-spacing: normal; line-height: normal; orphans: auto; te=
xt-align: start; text-indent: 0px; text-transform: none; white-space: norma=
l; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On 201=
4-05-27 22:54,<span class=3D"Apple-converted-space"> </span><a href=3D=
"mailto:jgottman6@gmail.com">jgottman6@gmail.com</a><span class=3D"Apple-co=
nverted-space"> </span>wrote:<br><blockquote type=3D"cite">On Tuesday,=
May 27, 2014 12:44:50 PM UTC-4, Matthew Woehlke wrote:<br><blockquote type=
=3D"cite">I suspect the benefit here isn't optimization, but rather code wr=
iting,<span class=3D"Apple-converted-space"> </span><br>e.g. to be abl=
e to write:<span class=3D"Apple-converted-space"> </span><br><br> =
;std::vector<int> v;<span class=3D"Apple-converted-space"> </spa=
n><br> v.clear().push_back(2).insert(v.begin(), 1); // etc.<span class=
=3D"Apple-converted-space"> </span><br><br>(Not the best example, but =
hopefully you get the idea.)<span class=3D"Apple-converted-space"> </s=
pan><br></blockquote><br>I get the idea, and this example accidentally show=
s why this is not a good<span class=3D"Apple-converted-space"> </span>=
<br>idea. The v.begin() passed to the insert() function might be the =
value of<span class=3D"Apple-converted-space"> </span><br>begin() at t=
he beginning of the statement. If the push_back() allocated<span clas=
s=3D"Apple-converted-space"> </span><br>memory (i.e. if v started with=
capacity() =3D=3D 0), then that iterator will<span class=3D"Apple-co=
nverted-space"> </span><br>be invalidated before the insert can be don=
e, resulting in undefined<span class=3D"Apple-converted-space"> </span=
><br>behavior. <br></blockquote><br>(Getting way OT...) If that=
's actually possible I'd be inclined to call<br>it a bug in the language. <=
/div></blockquote><div><br></div><div>The real bug is that we don’t h=
ave a way to explicitly express such ambiguity without putting things all o=
n one line.</div><div><br></div><div>If you want subexpressions to be evalu=
ated in deterministic order, then write in Java.</div><br><blockquote type=
=3D"cite"><div style=3D"font-size: 12px; font-style: normal; font-variant: =
normal; font-weight: normal; letter-spacing: normal; line-height: normal; o=
rphans: auto; text-align: start; text-indent: 0px; text-transform: none; wh=
ite-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-wid=
th: 0px;">I'm having a hard time imagining under what<br>circumstances it's=
desirable to evaluate the arguments for a method<br>invocation before you =
are able to know what object the method will be<br>invoked against.<br></di=
v></blockquote><div><br></div><div>You (the programmer) are responsible for=
making order of evaluation inconsequential. The compiler should be free to=
schedule things for the convenience of the CPU.</div></div><br></body></ht=
ml>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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=_F26B8504-9764-4A91-9D41-BFDFD2DB1590--
.