Topic: New overloads for pop methods
Author: morwenn29@gmail.com
Date: Thu, 20 Jun 2013 02:48:28 -0700 (PDT)
Raw View
------=_Part_2563_3203943.1371721708415
Content-Type: text/plain; charset=ISO-8859-1
A feature commonly esked for is a pop method for containers that would
return the popped value.
To be sure that the function actually returns something, even if the
container is empty, the user
shall provide a default value of type value_type which will be returned if
the container is empty.
The behaviour of the function would look like this (here, for std::stack):
template<typename T>
T pop(const T& default_value)
{
if (empty())
{
return default_value;
}
T ret = top();
pop();
return ret;
}
It's easy to extend this behaviour to pop_front and pop_back methods.
I bet that it has already been discussed back in time, but I did not find
any proof that a discussion
happened, so I just created my own. Since this overload does not exist, I
assume there are some
strong arguments against?
--
---
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_2563_3203943.1371721708415
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
A feature commonly esked for is a pop method for containers that would retu=
rn the popped value.<br>To be sure that the function actually returns somet=
hing, even if the container is empty, the user<br>shall provide a default v=
alue of type value_type which will be returned if the container is empty.<b=
r>The behaviour of the function would look like this (here, for std::stack)=
:<br><br> template<typename T><br>  =
; T pop(const T& default_value)<br> {<br> =
if (empty())<br> &nbs=
p; {<br> &=
nbsp; return default_value;<br> &n=
bsp; }<br> T ret =3D top();<br>&n=
bsp; pop();<br> =
return ret;<br> }<br><br>It's easy to =
extend this behaviour to pop_front and pop_back methods.<br>I bet that it h=
as already been discussed back in time, but I did not find any proof =
that a discussion<br>happened, so I just created my own. Since this overloa=
d does not exist, I assume there are some<br>strong arguments against?<br>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_2563_3203943.1371721708415--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Thu, 20 Jun 2013 03:22:53 -0700 (PDT)
Raw View
------=_Part_2157_24303136.1371723773876
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, June 20, 2013 10:48:28 AM UTC+1, morw...@gmail.com wrote:
>
> A feature commonly esked for is a pop method for containers that would
> return the popped value.
> To be sure that the function actually returns something, even if the
> container is empty, the user
> shall provide a default value of type value_type which will be returned if
> the container is empty.
> The behaviour of the function would look like this (here, for std::stack):
>
> template<typename T>
> T pop(const T& default_value)
> {
> if (empty())
> {
> return default_value;
> }
> T ret = top();
> pop();
> return ret;
> }
>
> It's easy to extend this behaviour to pop_front and pop_back methods.
> I bet that it has already been discussed back in time, but I did not find
> any proof that a discussion
> happened, so I just created my own. Since this overload does not exist, I
> assume there are some
> strong arguments against?
>
At the return statement, if the copy constructor of T throws an exception
you don't get the return value, but have already removed the element from
the container, so it is lost forever. If the object contained the only copy
of your swiss bank account details you have no way to access your money.
Much sadness ensues.
This is why std::stack forces you to access the top element separately from
popping it. If copying the top element throws, the original is still in the
container.
--
---
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_2157_24303136.1371723773876
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, June 20, 2013 10:48:28 AM UTC+1, morw...@gmail.com wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">A feature commonly esked fo=
r is a pop method for containers that would return the popped value.<br>To =
be sure that the function actually returns something, even if the container=
is empty, the user<br>shall provide a default value of type value_type whi=
ch will be returned if the container is empty.<br>The behaviour of the func=
tion would look like this (here, for std::stack):<br><br> =
template<typename T><br> T pop(const T& defaul=
t_value)<br> {<br> &nb=
sp; if (empty())<br> {<br> &=
nbsp; return default_=
value;<br> }<br>  =
; T ret =3D top();<br>  =
; pop();<br> return r=
et;<br> }<br><br>It's easy to extend this behaviour to po=
p_front and pop_back methods.<br>I bet that it has already been discussed b=
ack in time, but I did not find any proof that a discussion<br>happen=
ed, so I just created my own. Since this overload does not exist, I assume =
there are some<br>strong arguments against?<br></blockquote><div><br>At the=
return statement, if the copy constructor of T throws an exception you don=
't get the return value, but have already removed the element from the cont=
ainer, so it is lost forever. If the object contained the only copy of your=
swiss bank account details you have no way to access your money. Muc=
h sadness ensues.<br><br>This is why std::stack forces you to access the to=
p element separately from popping it. If copying the top element throws, th=
e original is still in the container.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_2157_24303136.1371723773876--
.
Author: morwenn29@gmail.com
Date: Thu, 20 Jun 2013 04:15:46 -0700 (PDT)
Raw View
------=_Part_6499_6591712.1371726946478
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le jeudi 20 juin 2013 12:22:53 UTC+2, Jonathan Wakely a =E9crit :
>
> At the return statement, if the copy constructor of T throws an exception=
=20
> you don't get the return value, but have already removed the element from=
=20
> the container, so it is lost forever. If the object contained the only co=
py=20
> of your swiss bank account details you have no way to access your money. =
=20
> Much sadness ensues.
>
> This is why std::stack forces you to access the top element separately=20
> from popping it. If copying the top element throws, the original is still=
=20
> in the container.
>
What about returning a RAII wrapper that can be converted to T and performs=
=20
the pop only when destructed?
Just kidding, I get your point.=20
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_6499_6591712.1371726946478
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Le jeudi 20 juin 2013 12:22:53 UTC+2, Jonathan Wakely a =E9crit :<br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div><br>At the return statemen=
t, if the copy constructor of T throws an exception you don't get the retur=
n value, but have already removed the element from the container, so it is =
lost forever. If the object contained the only copy of your swiss bank acco=
unt details you have no way to access your money. Much sadness ensues=
..<br><br>This is why std::stack forces you to access the top element separa=
tely from popping it. If copying the top element throws, the original is st=
ill in the container.<br></div></blockquote><div><br>What about returning a=
RAII wrapper that can be converted to T and performs the pop only when des=
tructed?<br>Just kidding, I get your point. <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_6499_6591712.1371726946478--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Thu, 20 Jun 2013 16:25:13 -0700 (PDT)
Raw View
------=_Part_171_99248.1371770713385
Content-Type: text/plain; charset=ISO-8859-1
More relevantly, that logic doesn't hold in a world of noexcept move
construction. There's no exception safety issue here if T's move
constructor is noexcept.
--
---
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_171_99248.1371770713385
Content-Type: text/html; charset=ISO-8859-1
More relevantly, that logic doesn't hold in a world of noexcept move construction. There's no exception safety issue here if T's move constructor is noexcept.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
------=_Part_171_99248.1371770713385--
.
Author: Nevin Liber <nliber@gmail.com>
Date: Thu, 20 Jun 2013 18:52:31 -0500
Raw View
> On Jun 20, 2013, at 6:25 PM, DeadMG <wolfeinstein@gmail.com> wrote:
>
> More relevantly, that logic doesn't hold in a world of noexcept move construction.
But that isn't the only world the standard has to support.
> There's no exception safety issue here if T's move constructor is noexcept.
There is no exception safety issue if T's copy constructor was throw()
in C++03 either.
I don't see how any of this is relevant, since the standard library
supports throwing move/copy constructors.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (312) 623-5420
--
---
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: Xeo <hivemaster@hotmail.de>
Date: Thu, 20 Jun 2013 17:11:39 -0700 (PDT)
Raw View
------=_Part_259_9289000.1371773499125
Content-Type: text/plain; charset=ISO-8859-1
On Friday, June 21, 2013 1:52:31 AM UTC+2, Nevin ":-)" Liber wrote:
> I don't see how any of this is relevant, since the standard library
> supports throwing move/copy constructors.
>
Maybe, but the stdlib also doesn't care if the move constructor throws -
for example, when regrowing a std::vector. If the type is move-only, it
will move regardless of noexcept-ness. If it's copyable, it will favor
noexcept move over copy over throwing move.
--
---
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_259_9289000.1371773499125
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, June 21, 2013 1:52:31 AM UTC+2, Nevin ":-)" Liber wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">I don't see how any of this is rel=
evant, since the standard library
<br>supports throwing move/copy constructors.
<br></blockquote><div><br>Maybe, but the stdlib also doesn't care if the mo=
ve constructor throws - for example, when regrowing a std::vector. If the t=
ype is move-only, it will move regardless of noexcept-ness. If it's copyabl=
e, it will favor noexcept move over copy over throwing move.<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_259_9289000.1371773499125--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Thu, 20 Jun 2013 17:12:48 -0700 (PDT)
Raw View
------=_Part_239_13732084.1371773568132
Content-Type: text/plain; charset=ISO-8859-1
There is precedence for enabling extra features for types with noexcept
moves if this is possible, and such a function would seem to be a good
candidate.
--
---
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_239_13732084.1371773568132
Content-Type: text/html; charset=ISO-8859-1
There is precedence for enabling extra features for types with noexcept moves if this is possible, and such a function would seem to be a good candidate.
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
------=_Part_239_13732084.1371773568132--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jun 2013 01:21:49 -0500
Raw View
--047d7bd7684860ec3504dfa4169e
Content-Type: text/plain; charset=ISO-8859-1
On 20 June 2013 19:11, Xeo <hivemaster@hotmail.de> wrote:
> On Friday, June 21, 2013 1:52:31 AM UTC+2, Nevin ":-)" Liber wrote:
>
>> I don't see how any of this is relevant, since the standard library
>> supports throwing move/copy constructors.
>>
>
> Maybe, but the stdlib also doesn't care if the move constructor throws -
> for example, when regrowing a std::vector. If the type is move-only, it
> will move regardless of noexcept-ness. If it's copyable, it will favor
> noexcept move over copy over throwing move.
>
Again, why is that relevant? That isn't a changing interface; just a best
effort to (a) preserve user data in the face of exceptions and (b) be
efficient (in that order).
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--047d7bd7684860ec3504dfa4169e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 20 June 2013 19:11, Xeo <span dir=3D"ltr"><<a href=3D"mailto:hivemast=
er@hotmail.de" target=3D"_blank">hivemaster@hotmail.de</a>></span> wrote=
:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im">On Friday, June 21, 2013 1:52:31 AM UTC+2, Nevin ":-=
)" Liber wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">I don't=
see how any of this is relevant, since the standard library
<br>supports throwing move/copy constructors.
<br></blockquote></div><div><br>Maybe, but the stdlib also doesn't care=
if the move constructor throws - for example, when regrowing a std::vector=
.. If the type is move-only, it will move regardless of noexcept-ness. If it=
's copyable, it will favor noexcept move over copy over throwing move.<=
br>
</div></blockquote><div><br></div><div>Again, why is that relevant? =A0That=
isn't a changing interface; just a best effort to (a) preserve user da=
ta in the face of exceptions and (b) be efficient (in that order).</div>
</div>
-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin=
@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=A0 (847=
) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--047d7bd7684860ec3504dfa4169e--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jun 2013 01:26:40 -0500
Raw View
--90e6ba3098a8ad6a0d04dfa42703
Content-Type: text/plain; charset=ISO-8859-1
On 20 June 2013 19:12, DeadMG <wolfeinstein@gmail.com> wrote:
> There is precedence for enabling extra features for types with noexcept
> moves if this is possible, and such a function would seem to be a good
> candidate.
Where is this precedence? The previous vector example is an implementation
detail, not an interface change.
So far, this just looks like being clever for the sake of being clever, and
nothing else. I would vote strongly against such a proposal.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--90e6ba3098a8ad6a0d04dfa42703
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 20 June 2013 19:12, DeadMG <span dir=3D"ltr"><<a href=3D"mailto:wolfe=
instein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>></span> =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is precedence for enabling extra features for types with noexcept mov=
es if this is possible, and such a function would seem to be a good candida=
te.</blockquote><div><br></div><div>Where is this precedence? =A0The previo=
us vector example is an implementation detail, not an interface change.</di=
v>
<div><br></div><div>So far, this just looks like being clever for the sake =
of being clever, and nothing else. =A0I would vote strongly against such a =
proposal.</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a=
href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlor=
d.com</a>>=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--90e6ba3098a8ad6a0d04dfa42703--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Fri, 21 Jun 2013 08:58:28 -0700 (PDT)
Raw View
------=_Part_475_921309.1371830308520
Content-Type: text/plain; charset=ISO-8859-1
Offering move semantics over copy semantics is *not an implementation
detail at all*. Not to mention the hideous performance ramifications of
copying over moving, but the existence of move-only types clearly shows
that being able to move, as opposed to copy, is a serious interface
consideration. A std::stack<std::unique_ptr<int>> is going to notice the
difference in the interface. I also notice that, at least according to
MSDN, there is only a const T& overload for `push`, preventing move-only
types.
This is exactly the same case as the std::vector- it's a serious interface
consideration which is important for the support of move-only types.
--
---
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_475_921309.1371830308520
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Offering move semantics over copy semantics is <i>not an implementatio=
n detail at all</i>. Not to mention the hideous performance ramifications o=
f copying over moving, but the existence of move-only types clearly shows t=
hat being able to move, as opposed to copy, is a serious interface consider=
ation. A std::stack<std::unique_ptr<int>> is going to notice th=
e difference in the interface. I also notice that, at least according to MS=
DN, there is only a const T& overload for `push`, preventing move-only =
types.<div><br></div><div>This is exactly the same case as the std::vector-=
it's a serious interface consideration which is important for the support =
of move-only types.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_475_921309.1371830308520--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 21 Jun 2013 11:26:46 -0500
Raw View
--089e0158ba5cd70fcf04dfac896f
Content-Type: text/plain; charset=ISO-8859-1
On 21 June 2013 10:58, DeadMG <wolfeinstein@gmail.com> wrote:
> Offering move semantics over copy semantics is *not an implementation
> detail at all*. Not to mention the hideous performance ramifications of
> copying over moving, but the existence of move-only types clearly shows
> that being able to move, as opposed to copy, is a serious interface
> consideration.
I have *no* idea what you are talking about. top() returns a *reference*;
if the user needs it as a value (which is typically far more expensive than
just using the reference), they can call std::move on it themselves.
What optimization does this schizophrenic interface proposal enable that
can't be done otherwise?
A std::stack<std::unique_ptr<int>> is going to notice the difference in the
> interface.
That's a tautology; if the interface is different, of course some people
will notice it. I fail to see any optimization benefits this opens up.
> I also notice that, at least according to MSDN, there is only a const T&
> overload for `push`, preventing move-only types.
I look at the standard or future drafts (such as N3690 for C++14) when
talking about what is in the standard, as 2nd hand sources may be out of
date, incorrect, or may only reflect current implementations.
> This is exactly the same case as the std::vector- it's a serious interface
> consideration which is important for the support of move-only types.
>
*shrug* Good luck with your proposal.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0158ba5cd70fcf04dfac896f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 21 June 2013 10:58, DeadMG <span dir=3D"ltr"><<a href=3D"mailto:wolfe=
instein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>></span> =
wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Offering move semantics over copy semantics is <i>not=A0an implementation d=
etail at all</i>. Not to mention the hideous performance ramifications of c=
opying over moving, but the existence of move-only types clearly shows that=
being able to move, as opposed to copy, is a serious interface considerati=
on.</blockquote>
<div><br>I have *no* idea what you are talking about.=A0 top() returns a <i=
>reference</i>; if the user needs it as a value (which is typically far mor=
e expensive than just using the reference), they can call std::move on it t=
hemselves.<br>
<br>What optimization does this schizophrenic interface proposal enable tha=
t can't be done otherwise?<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A std::stack<std::unique_ptr<int>> is going to notice the diff=
erence in the interface. </blockquote><div><br>That's a tautology; if t=
he interface is different, of course some people will notice it.=A0 I fail =
to see any optimization benefits this opens up.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">I also notice that, at least accord=
ing to MSDN, there is only a const T& overload for `push`, preventing m=
ove-only types.</blockquote>
<div><br>I look at the standard or future drafts (such as N3690 for C++14) =
when talking about what is in the standard, as 2nd hand sources may be out =
of date, incorrect, or may only reflect current implementations.<br>=A0</di=
v>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>This is exactly the same case as the st=
d::vector- it's a serious interface consideration which is important fo=
r the support of move-only types.<br clear=3D"all">
</div></blockquote><div><br>*shrug*=A0 Good luck with your proposal. <br></=
div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--089e0158ba5cd70fcf04dfac896f--
.
Author: Jonathan Wakely <cxx@kayari.org>
Date: Fri, 21 Jun 2013 09:40:51 -0700 (PDT)
Raw View
------=_Part_763_3902547.1371832851081
Content-Type: text/plain; charset=ISO-8859-1
On Friday, June 21, 2013 4:58:28 PM UTC+1, DeadMG wrote:
>
> Offering move semantics over copy semantics is *not an implementation
> detail at all*. Not to mention the hideous performance ramifications of
> copying over moving, but the existence of move-only types clearly shows
> that being able to move, as opposed to copy, is a serious interface
> consideration. A std::stack<std::unique_ptr<int>> is going to notice the
> difference in the interface. I also notice that, at least according to
> MSDN, there is only a const T& overload for `push`, preventing move-only
> types.
>
>
MSDN is wrong.
There is an issue with priority_queue::top() though, as *that* doesn't
support move-only types, the other adaptors are OK.
See
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/TIst1FOdveo/discussion
--
---
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_763_3902547.1371832851081
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, June 21, 2013 4:58:28 PM UTC+1, DeadMG wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Offering move semantics over copy semantics is =
<i>not an implementation detail at all</i>. Not to mention the hideous=
performance ramifications of copying over moving, but the existence of mov=
e-only types clearly shows that being able to move, as opposed to copy, is =
a serious interface consideration. A std::stack<std::unique_ptr<<wbr>=
int>> is going to notice the difference in the interface. I also noti=
ce that, at least according to MSDN, there is only a const T& overload =
for `push`, preventing move-only types.<div><br></div></blockquote><div><br=
>MSDN is wrong.<br><br>There is an issue with priority_queue::top() though,=
as *that* doesn't support move-only types, the other adaptors are OK.<br><=
br>See https://groups.google.com/a/isocpp.org/d/topic/std-proposals/TIst1FO=
dveo/discussion<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_763_3902547.1371832851081--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Fri, 21 Jun 2013 13:18:28 -0700
Raw View
On Thu, Jun 20, 2013 at 4:52 PM, Nevin Liber <nliber@gmail.com> wrote:
>> On Jun 20, 2013, at 6:25 PM, DeadMG <wolfeinstein@gmail.com> wrote:
>>
>> More relevantly, that logic doesn't hold in a world of noexcept move construction.
>
> But that isn't the only world the standard has to support.
>
>> There's no exception safety issue here if T's move constructor is noexcept.
>
> There is no exception safety issue if T's copy constructor was throw()
> in C++03 either.
>
> I don't see how any of this is relevant, since the standard library
> supports throwing move/copy constructors.
This seems to be a problem with the proposed implementation, not with
the idea; the function becomes exception safe if the pop is performed
*after* the return value is constructed. I don't think that's actually
possible to guarantee in current C++, but we can get very close. (We
could get all the way if we added Jens' std::uncaught_exception_count
feature, or if we had guaranteed copy-elision in some cases, for
instance.)
--
---
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: Sean Middleditch <sean.middleditch@gmail.com>
Date: Sat, 22 Jun 2013 12:35:40 -0700 (PDT)
Raw View
------=_Part_1215_12749339.1371929740713
Content-Type: text/plain; charset=ISO-8859-1
My original message seems to be stuck in a moderation queue for some time
now (forgot to "join" before sending that message), so I apologize if a
semi-duplicate shows up later.
In response to some of the concerns with exceptions in this proposal, and
more importantly a desire to add some consistency with concurrent queues,
I'd propose a slightly different addition; an example for just
vector::pop_back (easily expandable to the other pop* functions for deque,
list, and so on):
bool try_pop_back(T& out_value)
{
if (empty())
return false;
out_value = std::move(back());
pop_back();
return true;
}
// old way
if (!stack.empty())
{
auto v = stack.back();
stack.pop_back();
do_stuff(v);
}
// new way
decltype(c)::value_type v;
if (c.try_pop_back(v))
do_stuff(v);
// new way just wanting a default
decltype(c)::value_type v; // v could be explicitly initialized if a
different default value is needed
c.try_pop_back(v); // don't care if there was a value to pop or we're
just keeping the default value, no need to check return
do_stuff(v);
I'm not at all fond of needing to predeclare the out value using the more
verbose decltype syntax, but the result is still less code than now and
roughly the same efficiency and behavior of the proposed defaulted-value
pop_top(), minus the exception problems.
Far, far more importantly IMO is the part where the current interface
cannot be used for concurrent data structures. It's a huge race to
separately check if empty and then access an element and then pop that same
element from a data structure without wrapping the whole series of
operations in a lock, so a try_pop* type of interface is required for
lock-free efficient queues and other concurrent data structures. Adding
this version of the pop* function to all containers ensures that algorithms
can be written which are neutral to whether a particular container is a
concurrent variant or not (assuming this interface matches closely enough
the interface of any concurrent containers being adding to the library).
Note that wrappers like stack - to be compatible with concurrent types -
would need to implement try_pop_top as a wrapper over try_pop_back and the
like in order to maintain compatibility with concurrent types.
It's also better than a default value as for many containers there is no
sensible default value if you wanted to differentiate between "use default"
and "not there," but as demonstrated allows a similar use to the proposed
functions with only a little tiny bit more code (while still being
concurrency-friendly). For instance, with a vector of ints, there may not
be a sensible default int value that isn't a legal value to be stored in
the container, so you'd be forced to use the race-heavy current interface
to check if you're getting a default or not.
On Thursday, June 20, 2013 2:48:28 AM UTC-7, morw...@gmail.com wrote:
>
> A feature commonly esked for is a pop method for containers that would
> return the popped value.
> To be sure that the function actually returns something, even if the
> container is empty, the user
> shall provide a default value of type value_type which will be returned if
> the container is empty.
> The behaviour of the function would look like this (here, for std::stack):
>
> template<typename T>
> T pop(const T& default_value)
> {
> if (empty())
> {
> return default_value;
> }
> T ret = top();
> pop();
> return ret;
> }
>
> It's easy to extend this behaviour to pop_front and pop_back methods.
> I bet that it has already been discussed back in time, but I did not find
> any proof that a discussion
> happened, so I just created my own. Since this overload does not exist, I
> assume there are some
> strong arguments against?
>
--
---
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_1215_12749339.1371929740713
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
My original message seems to be stuck in a moderation queue for some time n=
ow (forgot to "join" before sending that message), so I apologize if a semi=
-duplicate shows up later.<div><br></div><div>In response to some of the co=
ncerns with exceptions in this proposal, and more importantly a desire to a=
dd some consistency with concurrent queues, I'd propose a slightly differen=
t addition; an example for just vector::pop_back (easily expandable to the =
other pop* functions for deque, list, and so on):</div><div><br></div><div>=
bool try_pop_back(T& out_value)<br></div><div> {</div><div=
> if (empty())</div><div> return false;</di=
v><div> out_value =3D std::move(back());</div><div> &nbs=
p; pop_back();</div><div> return true;</div><div> }</div=
><div><br></div><div> // old way</div><div> if (!stack.empty())=
</div><div> {</div><div> auto v =3D stack.back();</div><=
div> stack.pop_back();</div><div> do_stuff(v);</d=
iv><div> }</div><div><br></div><div> // new way</div><div> =
; decltype(c)::value_type v;</div><div> if (c.try_pop_back(v))</div><=
div> do_stuff(v);</div><div><br></div><div> // new way j=
ust wanting a default</div><div> decltype(c)::value_type v;=
// v could be explicitly initialized if a different default value is neede=
d</div><div> c.try_pop_back(v); // don't care if there was a value to=
pop or we're just keeping the default value, no need to check return</div>=
<div> do_stuff(v);</div><div><br></div><div>I'm not at all fond of ne=
eding to predeclare the out value using the more verbose decltype syntax, b=
ut the result is still less code than now and roughly the same efficiency a=
nd behavior of the proposed defaulted-value pop_top(), minus the exception =
problems.</div><div><br></div><div>Far, far more importantly IMO is the par=
t where the current interface cannot be used for concurrent data structures=
.. It's a huge race to separately check if empty and then access an el=
ement and then pop that same element from a data structure without wrapping=
the whole series of operations in a lock, so a try_pop* type of interface =
is required for lock-free efficient queues and other concurrent data struct=
ures. Adding this version of the pop* function to all containers ensu=
res that algorithms can be written which are neutral to whether a particula=
r container is a concurrent variant or not (assuming this interface matches=
closely enough the interface of any concurrent containers being adding to =
the library).<br></div><div><br></div><div>Note that wrappers like stack - =
to be compatible with concurrent types - would need to implement try_pop_to=
p as a wrapper over try_pop_back and the like in order to maintain compatib=
ility with concurrent types.</div><div><br></div><div>It's also better than=
a default value as for many containers there is no sensible default value =
if you wanted to differentiate between "use default" and "not there," but a=
s demonstrated allows a similar use to the proposed functions with only a l=
ittle tiny bit more code (while still being concurrency-friendly). Fo=
r instance, with a vector of ints, there may not be a sensible default int =
value that isn't a legal value to be stored in the container, so you'd be f=
orced to use the race-heavy current interface to check if you're getting a =
default or not.</div><div><br>On Thursday, June 20, 2013 2:48:28 AM UTC-7, =
morw...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">A feat=
ure commonly esked for is a pop method for containers that would return the=
popped value.<br>To be sure that the function actually returns something, =
even if the container is empty, the user<br>shall provide a default value o=
f type value_type which will be returned if the container is empty.<br>The =
behaviour of the function would look like this (here, for std::stack):<br><=
br> template<typename T><br> T po=
p(const T& default_value)<br> {<br> =
if (empty())<br> &nbs=
p; {<br> &=
nbsp; return default_value;<br> }=
<br> T ret =3D top();<br> &n=
bsp; pop();<br> =
return ret;<br> }<br><br>It's easy to extend=
this behaviour to pop_front and pop_back methods.<br>I bet that it has alr=
eady been discussed back in time, but I did not find any proof that a=
discussion<br>happened, so I just created my own. Since this overload does=
not exist, I assume there are some<br>strong arguments against?<br></block=
quote></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_1215_12749339.1371929740713--
.
Author: David Krauss <potswa@gmail.com>
Date: Sun, 23 Jun 2013 11:47:32 +0800
Raw View
--001a11c2675ce6344104dfca27b9
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Jun 20, 2013 at 5:48 PM, <morwenn29@gmail.com> wrote:
> To be sure that the function actually returns something, even if the
> container is empty, the user shall provide a default value of type
> value_type which will be returned if the container is empty.
>
You can add whatever interface you like using an adaptor. Now that we have
inheriting constructors, derivation from standard containers is viable.
This is doubly true for a
I don't think the default_value stuff will be very popular. pop*() on an
empty container is UB. Constructing a default value just to remove UB when
the user commits an error is very un-C++.
It would be nice to add a tag to pop() to enable range checking, as a
std::nothrow_t function parameter or function template argument.
For what it's worth, I don't comprehend the objections to popping into the
return value for nothrow moveable types. A throwing move constructor is
such a smell that a compiler really should issue a warning. Few users are
actually competent to understand the issue, and the code such a person
writes to get around it will be just as exception-unsafe, and likely add
more problems on top. If someone is surprised when pop() is void for their
throwing moveable type, they will at least get a handle on the issue, or
some keywords for online research that could lead to a real resolution of
design problems.
--
---
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/.
--001a11c2675ce6344104dfca27b9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 20, 2013 at 5:48 PM, <span dir=3D"ltr"><<a href=3D"mailto:m=
orwenn29@gmail.com" target=3D"_blank">morwenn29@gmail.com</a>></span> wr=
ote:<br><div class=3D"gmail_quote"><div>=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
To be sure that the function actually returns something, even if the contai=
ner is empty, the user shall provide a default value of type value_type whi=
ch will be returned if the container is empty.<br></blockquote><div>=A0</di=
v>
<div>You can add whatever interface you=20
like using an adaptor. Now that we have inheriting constructors,=20
derivation from standard containers is viable. This is doubly true for a <b=
r><div class=3D"gmail_quote"><div><br>I don't think the=20
default_value stuff will be very popular. pop*() on an empty container=20
is UB. Constructing a default value just to remove UB when the user=20
commits an error is very un-C++.<br><br>It would be nice to add a tag to po=
p() to enable range checking, as a std::nothrow_t function parameter or fun=
ction template argument.<br><br>For what it's worth, I don't compre=
hend the objections to popping into the return value for nothrow moveable t=
ypes. A throwing move constructor is such a smell that a compiler really sh=
ould issue a warning. Few users are actually competent to understand the is=
sue, and the code such a person writes to get around it will be just as exc=
eption-unsafe, and likely add more problems on top. If someone is surprised=
when pop() is void for their throwing moveable type, they will at least ge=
t a handle on the issue, or some keywords for online research that could le=
ad to a real resolution of design problems.<br>
</div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--001a11c2675ce6344104dfca27b9--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Mon, 24 Jun 2013 10:25:07 -0500
Raw View
--089e0158ba5cdc7c5504dfe806eb
Content-Type: text/plain; charset=ISO-8859-1
On 22 June 2013 22:47, David Krauss <potswa@gmail.com> wrote:
>
> For what it's worth, I don't comprehend the objections to popping into the
> return value for nothrow moveable types.
>
It makes the language *much* harder to learn. You have to go into
noexcept, implicit constructors, design decisions for the standard library
(changing string to vector<char> suddenly stops your code from compiling),
etc., just to explain the behavior.
Also, given current language rules, if you are clever it is performance
neutral (assuming both RVO and that you need it by value instead of by
reference); if not, it is a pessimization. A typical implementation in
pseudocode:
T pop_back()
{
T t(std::move(back())); // line 1
back().~T();
deallocate(&back());
return t;
}
Are compilers allowed to optimize out line 1? If not, then this is
*always* a pessimization on current code and generic code (since generic
code typically would not assume that the move constructors are marked
noexcept).
> A throwing move constructor is such a smell that a compiler really should
> issue a warning.
>
If you wish to propose that the standard library have all its move
constructors marked noexcept, well, good luck with that.
> Few users are actually competent to understand the issue, and the code
> such a person writes to get around it will be just as exception-unsafe, and
> likely add more problems on top.
>
Given that this has been the status quo for a decade and a half, can you
please show the real world examples you have encountered where the code to
get around this is exception-unsafe and has more problems? We would all
benefit from your experience in this area.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0158ba5cdc7c5504dfe806eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 22 June 2013 22:47, David Krauss <span dir=3D"ltr"><<a href=3D"mailto=
:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> wrote:=
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class=3D"gmail_quote"><div><div class=3D"gmail_quote"><div>For wha=
t it's worth, I don't comprehend the objections to popping into the=
return value for nothrow moveable types. </div></div></div></div></blockqu=
ote>
<div><br>It makes the language *much* harder to learn.=A0 You have to go in=
to noexcept, implicit constructors, design decisions for the standard libra=
ry (changing string to vector<char> suddenly stops your code from com=
piling), etc., just to explain the behavior.<br>
</div><div><br>Also, given current language rules, if you are clever it is =
performance neutral (assuming both RVO and that you need it by value instea=
d of by reference); if not, it is a pessimization.=A0 A typical implementat=
ion in pseudocode:<br>
<br>T pop_back()<br>{<br>=A0=A0=A0 T t(std::move(back()));=A0 // line 1<br>=
=A0=A0=A0 back().~T();<br>=A0=A0=A0 deallocate(&back());<br>=A0=A0=A0 r=
eturn t;<br>}<br><br>Are compilers allowed to optimize out line 1?=A0 If no=
t, then this is *always* a pessimization on current code and generic code (=
since generic code typically would not assume that the move constructors ar=
e marked noexcept).<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div class=3D"gmail_quote"><div><di=
v class=3D"gmail_quote"><div>A throwing move constructor is such a smell th=
at a compiler really should issue a warning.</div>
</div></div></div></blockquote><div><br>If you wish to propose that the sta=
ndard library have all its move constructors marked noexcept, well, good lu=
ck with that.<br>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"gmail_quote"><div><div class=3D"gmail_quote"><div> Few users =
are actually competent to understand the issue, and the code such a person =
writes to get around it will be just as exception-unsafe, and likely add mo=
re problems on top. </div>
</div></div></div></blockquote><div><br>Given that this has been the status=
quo for a decade and a half, can you please show the real world examples y=
ou have encountered where the code to get around this is exception-unsafe a=
nd has more problems?=A0 We would all benefit from your experience in this =
area.<br>
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--089e0158ba5cdc7c5504dfe806eb--
.
Author: Lawrence Crowl <crowl@googlers.com>
Date: Mon, 24 Jun 2013 20:02:50 -0700
Raw View
On 6/22/13, Sean Middleditch <sean.middleditch@gmail.com> wrote:
> My original message seems to be stuck in a moderation queue for some time
> now (forgot to "join" before sending that message), so I apologize if a
> semi-duplicate shows up later.
>
> In response to some of the concerns with exceptions in this proposal, and
> more importantly a desire to add some consistency with concurrent queues,
See N3533.
> I'd propose a slightly different addition; an example for just
> vector::pop_back (easily expandable to the other pop* functions for deque,
> list, and so on):
>
> bool try_pop_back(T& out_value)
> {
> if (empty())
> return false;
> out_value = std::move(back());
> pop_back();
> return true;
> }
>
> // old way
> if (!stack.empty())
> {
> auto v = stack.back();
> stack.pop_back();
> do_stuff(v);
> }
>
> // new way
> decltype(c)::value_type v;
> if (c.try_pop_back(v))
> do_stuff(v);
>
> // new way just wanting a default
> decltype(c)::value_type v; // v could be explicitly initialized if a
> different default value is needed
> c.try_pop_back(v); // don't care if there was a value to pop or we're
> just keeping the default value, no need to check return
> do_stuff(v);
>
> I'm not at all fond of needing to predeclare the out value using the more
> verbose decltype syntax, but the result is still less code than now and
> roughly the same efficiency and behavior of the proposed defaulted-value
> pop_top(), minus the exception problems.
>
> Far, far more importantly IMO is the part where the current interface
> cannot be used for concurrent data structures. It's a huge race to
> separately check if empty and then access an element and then pop that same
>
> element from a data structure without wrapping the whole series of
> operations in a lock, so a try_pop* type of interface is required for
> lock-free efficient queues and other concurrent data structures. Adding
> this version of the pop* function to all containers ensures that algorithms
>
> can be written which are neutral to whether a particular container is a
> concurrent variant or not (assuming this interface matches closely enough
> the interface of any concurrent containers being adding to the library).
>
> Note that wrappers like stack - to be compatible with concurrent types -
> would need to implement try_pop_top as a wrapper over try_pop_back and the
> like in order to maintain compatibility with concurrent types.
>
> It's also better than a default value as for many containers there is no
> sensible default value if you wanted to differentiate between "use default"
>
> and "not there," but as demonstrated allows a similar use to the proposed
> functions with only a little tiny bit more code (while still being
> concurrency-friendly). For instance, with a vector of ints, there may not
> be a sensible default int value that isn't a legal value to be stored in
> the container, so you'd be forced to use the race-heavy current interface
> to check if you're getting a default or not.
>
> On Thursday, June 20, 2013 2:48:28 AM UTC-7, morw...@gmail.com wrote:
>>
>> A feature commonly esked for is a pop method for containers that would
>> return the popped value.
>> To be sure that the function actually returns something, even if the
>> container is empty, the user
>> shall provide a default value of type value_type which will be returned if
>>
>> the container is empty.
>> The behaviour of the function would look like this (here, for
>> std::stack):
>>
>> template<typename T>
>> T pop(const T& default_value)
>> {
>> if (empty())
>> {
>> return default_value;
>> }
>> T ret = top();
>> pop();
>> return ret;
>> }
>>
>> It's easy to extend this behaviour to pop_front and pop_back methods.
>> I bet that it has already been discussed back in time, but I did not find
>>
>> any proof that a discussion
>> happened, so I just created my own. Since this overload does not exist, I
>>
>> assume there are some
>> strong arguments against?
>>
>
> --
>
> ---
> 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/.
>
>
>
--
Lawrence Crowl
--
---
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: Sean Middleditch <sean.middleditch@gmail.com>
Date: Wed, 26 Jun 2013 14:53:08 -0700 (PDT)
Raw View
------=_Part_1165_1459564.1372283589012
Content-Type: text/plain; charset=ISO-8859-1
On Monday, June 24, 2013 8:02:50 PM UTC-7, Lawrence Crowl wrote:
> On 6/22/13, Sean Middleditch <sean.mid...@gmail.com <javascript:>> wrote:
> > My original message seems to be stuck in a moderation queue for some
> time
> > now (forgot to "join" before sending that message), so I apologize if a
> > semi-duplicate shows up later.
> >
> > In response to some of the concerns with exceptions in this proposal,
> and
> > more importantly a desire to add some consistency with concurrent
> queues,
>
> See N3533.
>
Forgive me if I'm missing something, I'm not sure if you were just adding
information or try to make a counter-point, but my point was to add
compatible member functions to the existing non-concurrent interfaces to
match those added in N3533.
--
---
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_1165_1459564.1372283589012
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, June 24, 2013 8:02:50 PM UTC-7, Lawrence Crowl wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On 6/22/13, Sean Middleditch <<a h=
ref=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Q9fmOHRmLp0J=
">sean.mid...@gmail.com</a>> wrote:
<br>> My original message seems to be stuck in a moderation queue for so=
me time
<br>> now (forgot to "join" before sending that message), so I apologize=
if a
<br>> semi-duplicate shows up later.
<br>>
<br>> In response to some of the concerns with exceptions in this propos=
al, and
<br>> more importantly a desire to add some consistency with concurrent =
queues,
<br>
<br>See N3533.
<br></blockquote><div><br></div><div>Forgive me if I'm missing something, I=
'm not sure if you were just adding information or try to make a counter-po=
int, but my point was to add compatible member functions to the existing no=
n-concurrent interfaces to match those added in N3533.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_1165_1459564.1372283589012--
.
Author: sean.middleditch@gmail.com
Date: Thu, 20 Jun 2013 11:50:10 -0700 (PDT)
Raw View
------=_Part_13_29044783.1371754210450
Content-Type: text/plain; charset=ISO-8859-1
An alternative then might be a try_pop_back (and so on), something like:
bool try_pop_back(T& out)
{
if (empty())
return false;
out = std::move(back());
pop_back();
return true;
}
The pop_back() won't get called until after the move assignment into the
"final" destination is complete (so exceptions shouldn't be any more of a
problem than they usually are), and this variant has the added bonus that
you can easily check if something exists while retrieving it without
dealing with a default value, which at least personally I've found
significantly more useful than wanting a default value. It makes code like
the following just a little sweeter:
// current way
if (!foo.empty())
{
auto v = foo.back();
foo.pop_back();
something(v);
}
// new way
element_t v;
if (foo.try_pop_back(v))
something(v);
The big downside is that you must predeclare/initialize the output
variable, which also means you can't really use auto (I can think of ways
the language could make this nicer, but that's an entirely different
discussion).
One big upside is that the semantics can be made to match the concurrent
queue proposals and popular concurrency libraries such that there's a nice
consistent API between concurrent and non-concurrent containers which makes
writing algorithms and such way easier. This matters in particular because
the "current way" is a non-starter for concurrent queues due to an obvious
race. Having one interface that works on all containers seems to me like a
gigantic win.
On Thursday, June 20, 2013 3:22:53 AM UTC-7, Jonathan Wakely wrote:
>
>
>
> On Thursday, June 20, 2013 10:48:28 AM UTC+1, morw...@gmail.com wrote:
>>
>> A feature commonly esked for is a pop method for containers that would
>> return the popped value.
>> To be sure that the function actually returns something, even if the
>> container is empty, the user
>> shall provide a default value of type value_type which will be returned
>> if the container is empty.
>> The behaviour of the function would look like this (here, for std::stack):
>>
>> template<typename T>
>> T pop(const T& default_value)
>> {
>> if (empty())
>> {
>> return default_value;
>> }
>> T ret = top();
>> pop();
>> return ret;
>> }
>>
>> It's easy to extend this behaviour to pop_front and pop_back methods.
>> I bet that it has already been discussed back in time, but I did not
>> find any proof that a discussion
>> happened, so I just created my own. Since this overload does not exist, I
>> assume there are some
>> strong arguments against?
>>
>
> At the return statement, if the copy constructor of T throws an exception
> you don't get the return value, but have already removed the element from
> the container, so it is lost forever. If the object contained the only copy
> of your swiss bank account details you have no way to access your money.
> Much sadness ensues.
>
> This is why std::stack forces you to access the top element separately
> from popping it. If copying the top element throws, the original is still
> in the container.
>
--
---
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_13_29044783.1371754210450
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
An alternative then might be a try_pop_back (and so on), something like:<di=
v><br></div><div> bool try_pop_back(T& out)</div><div> =
; {</div><div> if (empty())</div><div>  =
; return false;</div><div> out =3D std::mov=
e(back());</div><div> pop_back();</div><div>  =
; return true;</div><div> }</div><div><br></div><div>The =
pop_back() won't get called until after the move assignment into the "final=
" destination is complete (so exceptions shouldn't be any more of a problem=
than they usually are), and this variant has the added bonus that you can =
easily check if something exists while retrieving it without dealing with a=
default value, which at least personally I've found significantly more use=
ful than wanting a default value. It makes code like the following ju=
st a little sweeter:</div><div><br></div><div> // current way</=
div><div> if (!foo.empty())</div><div> {</div><div>=
auto v =3D foo.back();</div><div> fo=
o.pop_back();</div><div> something(v);</div><div> =
}</div><div><br></div><div> // new way</div><div> &=
nbsp;element_t v;</div><div> if (foo.try_pop_back(v))</div><div=
> something(v);</div><div><br></div><div>The big downsid=
e is that you must predeclare/initialize the output variable, which also me=
ans you can't really use auto (I can think of ways the language could make =
this nicer, but that's an entirely different discussion).</div><div><br></d=
iv><div>One big upside is that the semantics can be made to match the concu=
rrent queue proposals and popular concurrency libraries such that there's a=
nice consistent API between concurrent and non-concurrent containers which=
makes writing algorithms and such way easier. This matters in partic=
ular because the "current way" is a non-starter for concurrent queues due t=
o an obvious race. Having one interface that works on all containers =
seems to me like a gigantic win.<br><br>On Thursday, June 20, 2013 3:22:53 =
AM UTC-7, Jonathan Wakely wrote:<blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><br><br>On Thursday, June 20, 2013 10:48:28 AM UTC+1, <a>morw...@gmail.co=
m</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left=
:0.8ex;border-left:1px #ccc solid;padding-left:1ex">A feature commonly eske=
d for is a pop method for containers that would return the popped value.<br=
>To be sure that the function actually returns something, even if the conta=
iner is empty, the user<br>shall provide a default value of type value_type=
which will be returned if the container is empty.<br>The behaviour of the =
function would look like this (here, for std::stack):<br><br> &n=
bsp; template<typename T><br> T pop(const T& de=
fault_value)<br> {<br>  =
; if (empty())<br> {<br>&nb=
sp; return defa=
ult_value;<br> }<br> &=
nbsp; T ret =3D top();<br> &=
nbsp; pop();<br> retu=
rn ret;<br> }<br><br>It's easy to extend this behaviour t=
o pop_front and pop_back methods.<br>I bet that it has already been discuss=
ed back in time, but I did not find any proof that a discussion<br>ha=
ppened, so I just created my own. Since this overload does not exist, I ass=
ume there are some<br>strong arguments against?<br></blockquote><div><br>At=
the return statement, if the copy constructor of T throws an exception you=
don't get the return value, but have already removed the element from the =
container, so it is lost forever. If the object contained the only copy of =
your swiss bank account details you have no way to access your money. =
Much sadness ensues.<br><br>This is why std::stack forces you to access th=
e top element separately from popping it. If copying the top element throws=
, the original is still in the container.<br></div></blockquote></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_13_29044783.1371754210450--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 27 Jun 2013 13:53:39 -0500
Raw View
--001a11c3acf82ae81204e0274a7a
Content-Type: text/plain; charset=ISO-8859-1
On 20 June 2013 13:50, <sean.middleditch@gmail.com> wrote:
> An alternative then might be a try_pop_back (and so on), something like:
>
> bool try_pop_back(T& out)
> {
> if (empty())
> return false;
> out = std::move(back());
> pop_back();
> return true;
> }
>
> The pop_back() won't get called until after the move assignment into the
> "final" destination is complete (so exceptions shouldn't be any more of a
> problem than they usually are),
>
Except with the current two liner, it is obvious in user code that user
left the back() element in a weird state.
> and this variant has the added bonus that you can easily check if
> something exists while retrieving it without dealing with a default value,
> which at least personally I've found significantly more useful than wanting
> a default value. It makes code like the following just a little sweeter:
>
> // current way
> if (!foo.empty())
> {
> auto v = foo.back();
> foo.pop_back();
> something(v);
> }
>
> // new way
> element_t v;
> if (foo.try_pop_back(v))
> something(v);
>
> The big downside is that you must predeclare/initialize the output
> variable, which also means you can't really use auto (I can think of ways
> the language could make this nicer, but that's an entirely different
> discussion).
>
In other words, it is *still* a pessimization.
The original question was is about turning a two-liner into a one-liner.
This is way more complicated for very little gain and no practical
experience. I would vote strongly against such a proposal, if it were to
come up.
--
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a11c3acf82ae81204e0274a7a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 20 June 2013 13:50, <span dir=3D"ltr"><<a href=3D"mailto:sean.middle=
ditch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com</a>></span=
> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
An alternative then might be a try_pop_back (and so on), something like:<di=
v><br></div><div>=A0 =A0bool try_pop_back(T& out)</div><div>=A0 =A0{</d=
iv><div>=A0 =A0 =A0if (empty())</div><div>=A0 =A0 =A0 =A0return false;</div=
><div>=A0 =A0 =A0out =3D std::move(back());</div>
<div>=A0 =A0 =A0pop_back();</div><div>=A0 =A0 =A0return true;</div><div>=A0=
=A0}</div><div><br></div><div>The pop_back() won't get called until af=
ter the move assignment into the "final" destination is complete =
(so exceptions shouldn't be any more of a problem than they usually are=
), </div>
</blockquote><div><br>Except with the current two liner, it is obvious in u=
ser code that user left the back() element in a weird state.<br>=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div>and this variant has the added bonus that you can easily check if some=
thing exists while retrieving it without dealing with a default value, whic=
h at least personally I've found significantly more useful than wanting=
a default value. =A0It makes code like the following just a little sweeter=
:</div>
<div><br></div><div>=A0 =A0// current way</div><div>=A0 =A0if (!foo.empty()=
)</div><div>=A0 =A0{</div><div>=A0 =A0 =A0auto v =3D foo.back();</div><div>=
=A0 =A0 =A0foo.pop_back();</div><div>=A0 =A0 =A0something(v);</div><div>=A0=
=A0}</div><div><br></div><div>
=A0 =A0// new way</div>
<div>=A0 =A0element_t v;</div><div>=A0 =A0if (foo.try_pop_back(v))</div><di=
v>=A0 =A0 =A0something(v);</div><div><br></div><div>The big downside is tha=
t you must predeclare/initialize the output variable, which also means you =
can't really use auto (I can think of ways the language could make this=
nicer, but that's an entirely different discussion).</div>
</blockquote><div><br>In other words, it is <i>still</i> a pessimization.<b=
r><br>The original question was is about turning a two-liner into a one-lin=
er.=A0 This is way more complicated for very little gain and no practical e=
xperience.=A0 I would vote strongly against such a proposal, if it were to =
come up.<br clear=3D"all">
</div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
>=A0 (847) 691-1404
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
--001a11c3acf82ae81204e0274a7a--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Tue, 2 Jul 2013 17:01:15 -0700 (PDT)
Raw View
------=_Part_3197_27490301.1372809675921
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, June 27, 2013 11:53:39 AM UTC-7, Nevin ":-)" Liber wrote:
> The pop_back() won't get called until after the move assignment into the
>> "final" destination is complete (so exceptions shouldn't be any more of a
>> problem than they usually are),
>>
>
> Except with the current two liner, it is obvious in user code that user
> left the back() element in a weird state.
>
Exceptions should not be leaving things in "weird" states, especially in a
move constructor, or you are already in enough trouble. If your move
constructor can throw an exception after _partially_ moving, you have
potentially serious problems all through the standard library and elsewhere
in your code. The exception problems with the OP suggestion are avoided
with mine entirely.
>
>> The big downside is that you must predeclare/initialize the output
>> variable, which also means you can't really use auto (I can think of ways
>> the language could make this nicer, but that's an entirely different
>> discussion).
>>
>
> In other words, it is *still* a pessimization.
>
I'm not sure what you mean by that.
> The original question was is about turning a two-liner into a one-liner.
> This is way more complicated for very little gain and no practical
> experience. I would vote strongly against such a proposal, if it were to
> come up.
>
No, it isn't. The existing code is not two lines. The original proposal
is about popping values, getting the back value, and safely handling the
case of an empty container, so that following logic can work independent of
whether the container had been empty or not. That's 5 lines at best right
now, 6 with some formatting styles.
value v{};
if (!c.empty()) {
v = c.back();
c.pop_back();
}
With the OP suggestion, that turns into a nicely concise:
auto v = c.pop_back({});
Compared to the version I suggested:
value v;
c.try_pop_back(v);
So yes, my suggestion is ever so slightly more verbose than the one in the
original suggestion, but it's still more concise than what we have now, It
also has the advantage that in cases where you actually care if the
container was empty and a defaulted value is not sufficient (say, a stack
of integers, or std::string, etc.) it still works. Extrapolating to data
structures like set or map, a try_erase(key) is also a big improvement:
// now
auto it = map.find(key);
if (it != map.end())
map.erase(key);
use(it->second);
// try_erase
value v;
if (map.try_erase(key, v))
use(v);
Going a bit down that rabbit hole, various alternative versions of
unordered_map and unordered_set which can contain significant performances
improvements over the stdlib implementations (by having different
conditions, e.g. allowing insert and erase to invalidate iterators and
requiring that value move assignment is noexcept) once again cannot be
implemented using the old-style interface (since you can't find an
iterator, erase its key, and then reuse that iterator), and the original
proposal doesn't work for types which have no "nil" state (and you may not
want or just can't use something like std::optional<> for values). Not
supporting the generic and reusable-everywhere interface just makes C++
more complicated to use.
Plus, not that I enjoy hitting the same nail repeatedly, but consistency
with concurrent containers would be nice.
--
---
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_3197_27490301.1372809675921
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Thursday, June 27, 2013 11:53:39 AM UTC-7, Nevin ":-)" Liber wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>The pop_back() won't get called until after=
the move assignment into the "final" destination is complete (so exception=
s shouldn't be any more of a problem than they usually are), </div>
</blockquote><div><br>Except with the current two liner, it is obvious in u=
ser code that user left the back() element in a weird state.<br></div></div=
></blockquote><div><br></div><div>Exceptions should not be leaving things i=
n "weird" states, especially in a move constructor, or you are already in e=
nough trouble. If your move constructor can throw an exception after =
_partially_ moving, you have potentially serious problems all through the s=
tandard library and elsewhere in your code. The exception problems wi=
th the OP suggestion are avoided with mine entirely.</div><div> </div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div><br></div><div>The big downside is that yo=
u must predeclare/initialize the output variable, which also means you can'=
t really use auto (I can think of ways the language could make this nicer, =
but that's an entirely different discussion).</div>
</blockquote><div><br>In other words, it is <i>still</i> a pessimization.<b=
r></div></div></blockquote><div><br></div><div> I'm not sure what you =
mean by that.</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=
=3D"gmail_quote"><div>The original question was is about turning a two-line=
r into a one-liner. This is way more complicated for very little gain=
and no practical experience. I would vote strongly against such a pr=
oposal, if it were to come up.<br clear=3D"all"></div></div></blockquote><d=
iv><br></div><div>No, it isn't. The existing code is not two lines. &=
nbsp; The original proposal is about popping values, getting the back value=
, and safely handling the case of an empty container, so that following log=
ic can work independent of whether the container had been empty or not. &nb=
sp;That's 5 lines at best right now, 6 with some formatting styles.</div><d=
iv><br></div><div> value v{};</div><div> if (!c.emp=
ty()) {</div><div> v =3D c.back();</div><div> &nbs=
p; c.pop_back();</div><div> }</div><div><br></div><div>Wi=
th the OP suggestion, that turns into a nicely concise:</div><div><br></div=
><div> auto v =3D c.pop_back({});<br></div><div><br></div><div>=
Compared to the version I suggested:</div><div><br></div><div> =
value v;</div><div> c.try_pop_back(v);</div><div><br></div><div=
>So yes, my suggestion is ever so slightly more verbose than the one in the=
original suggestion, but it's still more concise than what we have now, &n=
bsp;It also has the advantage that in cases where you actually care if the =
container was empty and a defaulted value is not sufficient (say, a stack o=
f integers, or std::string, etc.) it still works. Extrapolating to da=
ta structures like set or map, a try_erase(key) is also a big improvement:<=
/div><div><br></div><div> // now</div><div> auto it =3D map.fin=
d(key);</div><div> if (it !=3D map.end())</div><div> map=
..erase(key);</div><div> use(it->second);</div><div><br></div><div>=
// try_erase</div><div> value v;</div><div> if (map.try_=
erase(key, v))</div><div> use(v);</div><div><br></div><div>Goi=
ng a bit down that rabbit hole, various alternative versions of unordered_m=
ap and unordered_set which can contain significant performances improvement=
s over the stdlib implementations (by having different conditions, e.g. all=
owing insert and erase to invalidate iterators and requiring that value mov=
e assignment is noexcept) once again cannot be implemented using the old-st=
yle interface (since you can't find an iterator, erase its key, and then re=
use that iterator), and the original proposal doesn't work for types which =
have no "nil" state (and you may not want or just can't use something like =
std::optional<> for values). Not supporting the generic and reu=
sable-everywhere interface just makes C++ more complicated to use.</div><di=
v><br></div><div>Plus, not that I enjoy hitting the same nail repeatedly, b=
ut consistency with concurrent containers would be nice.</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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_3197_27490301.1372809675921--
.