Topic: Have container member functions return useful
Author: Vittorio Romeo <vittorio.romeo@outlook.com>
Date: Tue, 23 Sep 2014 23:36:53 +0200
Raw View
--_9683f8e2-7ac2-49e8-bc5e-2e7397e61116_
Content-Type: text/plain; charset=ISO-8859-1
`pop()` (and probably the other functions as well) do not return a value because of exception safety issues.
Read here first:
http://cpptruths.blogspot.it/2005/10/why-does-stdstackpop-returns-void.htmlhttp://blogs.msdn.com/b/zhanli/archive/2010/06/29/c-tips-why-the-pop-method-of-stl-stack-does-not-return-a-value.aspx
Then here - what you suggest could actually be possible, however only in specific cases:
http://stackoverflow.com/questions/9191781/can-queuepop-return-a-value-now
--
---
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/.
--_9683f8e2-7ac2-49e8-bc5e-2e7397e61116_
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<style><!--
..hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class=3D'hmmessage'><div dir=3D'ltr'>`pop()` (and probably the other =
functions as well) do not return a value because of exception safety issues=
..<br><br><div>Read here first:<br><a href=3D"http://cpptruths.blogspot.it/2=
005/10/why-does-stdstackpop-returns-void.html" target=3D"_blank">http://cpp=
truths.blogspot.it/2005/10/why-does-stdstackpop-returns-void.html</a><div><=
a href=3D"http://blogs.msdn.com/b/zhanli/archive/2010/06/29/c-tips-why-the-=
pop-method-of-stl-stack-does-not-return-a-value.aspx" target=3D"_blank">htt=
p://blogs.msdn.com/b/zhanli/archive/2010/06/29/c-tips-why-the-pop-method-of=
-stl-stack-does-not-return-a-value.aspx</a></div><div><br></div><div>Then h=
ere - what you suggest could actually be possible, however only in specific=
cases:<br><a href=3D"http://stackoverflow.com/questions/9191781/can-queuep=
op-return-a-value-now" target=3D"_blank">http://stackoverflow.com/questions=
/9191781/can-queuepop-return-a-value-now</a></div></div> </div><=
/body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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 />
--_9683f8e2-7ac2-49e8-bc5e-2e7397e61116_--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Tue, 23 Sep 2014 16:43:21 -0500
Raw View
--047d7bae47b027113f0503c27775
Content-Type: text/plain; charset=UTF-8
On 23 September 2014 16:13, Jeremy T <jeremy8258@gmail.com> wrote:
> *I. pop**
> Most of the standard containers include one or more of pop(), pop_front(),
> or pop_back(). All of these functions return type void. Personally, I
> have never used one of these functions without preceding it with a call to
> <container>.front() or <container>.back() to first obtain the element I'm
> about to pop. Therefore, I propose that all of the pop* functions have
> their signatures and logic changed to
>
> container::value_type pop*();
>
> Notice it returns a value rather than a reference or iterator. With move
> semantics, such an operation is no longer expensive, and with RVO, the copy
> (or move) would be avoided altogether.
>
Discussed (to death, IMNSHO) in the past. Breaking change, because your
pop() can throw an exception, as well as more expensive for existing code,
as that code would just throw away the return value even though internal to
the container it must be copied/moved (even with RVO). One of the reasons
for the back()/pop_back() split is because neither can throw, and you only
pay the copying/moving cost if you need it. IMO extremely unlikely to
pass. I'd vote strongly against it.
>
> *II. Have std::[forward_]list::splice[_forward]() return an iterator*
> Indeed, the above is the necessary method to perform such a task. Thus, I
> propose that std::list::splice() return a similar value. Specifically,
> that its declaration be changed to
>
> iterator splice (iterator position, list& x, iterator first, iterator last
> );
>
> with its return value being "an iterator pointing to the element that
> followed the last element in x transferred by the function call. This is
> the container end if the operation transferred the last element in the
> sequence."
>
std::list has six signatures for splice; I assume that you wish to change
all six.
Anyway, I don't particularly have a particularly strong opinion on this
one, as I rarely splice lists together. As long as it doesn't incur an
extra bookkeeping cost in the implementation of splice (other than
returning an iterator it was already keeping track of) I wouldn't be
against it.
--
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/.
--047d7bae47b027113f0503c27775
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 23 September 2014 16:13, Jeremy T <span dir=3D"ltr"><=
;<a href=3D"mailto:jeremy8258@gmail.com" target=3D"_blank">jeremy8258@gmail=
..com</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b>I. pop*</b><br>=
Most of the standard containers include one or more of <span style=3D"color=
:rgb(0,0,255)">pop()</span>, <span style=3D"color:rgb(0,0,255)">pop_front()=
</span>, or <span style=3D"color:rgb(0,0,255)">pop_back()</span>. All of th=
ese functions return type <span style=3D"color:rgb(0,0,255)">void</span>. P=
ersonally, I have never used one of these functions without preceding it wi=
th a call to <span style=3D"color:rgb(0,0,255)"><container>.front()</=
span> or <span style=3D"color:rgb(0,0,255)"><container>.back()</span>=
to first obtain the element I'm about to pop. Therefore, I propose tha=
t all of the <span style=3D"color:rgb(0,0,255)">pop*</span> functions have =
their signatures and logic changed to<br><br><div style=3D"background-color=
:rgb(250,250,250);border-color:rgb(187,187,187);border-style:solid;border-w=
idth:1px;word-wrap:break-word"><code><div><span style=3D"color:#000">contai=
ner</span><span style=3D"color:#660">::</span><span style=3D"color:#000">va=
lue_type pop</span><span style=3D"color:#660">*();</span><span style=3D"col=
or:#000"><br></span></div></code></div><br>Notice it returns a value rather=
than a reference or iterator. With move semantics, such an operation is no=
longer expensive, and with RVO, the copy (or move) would be avoided altoge=
ther.<br></div></blockquote><div><br></div><div>Discussed (to death, IMNSHO=
) in the past.=C2=A0 Breaking change, because your pop() can throw an excep=
tion, as well as more expensive for existing code, as that code would just =
throw away the return value even though internal to the container it must b=
e copied/moved (even with RVO).=C2=A0 One of the reasons for the back()/pop=
_back() split is because neither can throw, and you only pay the copying/mo=
ving cost if you need it.=C2=A0 IMO extremely unlikely to pass.=C2=A0 I'=
;d vote strongly against it.</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><br><b>II. Have std::[forward_]list::splice[_forward]() return an =
iterator</b><br>Indeed, the above is the necessary method to perform such a=
task. Thus, I propose that <span style=3D"color:rgb(0,0,255)">std::list::s=
plice()</span> return a similar value. Specifically, that its declaration b=
e changed to<br><br><div 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><div><span style=3D"color:#000">iterator splice </span><span st=
yle=3D"color:#660">(</span><span style=3D"color:#000">iterator position</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> list</spa=
n><span style=3D"color:#660">&</span><span style=3D"color:#000"> x</spa=
n><span style=3D"color:#660">,</span><span style=3D"color:#000"> iterator f=
irst</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> i=
terator </span><span style=3D"color:#008">last</span><span style=3D"color:#=
660">);</span><span style=3D"color:#000"><br></span></div></code></div><br>=
with its return value being "an iterator pointing to the element that =
followed the last element <span style=3D"color:rgb(0,0,255)">in x</span> tr=
ansferred by the function call. This is the container end if the operation =
transferred the last element in the sequence."<br></div></blockquote><=
div><br></div><div>std::list has six signatures for splice; I assume that y=
ou wish to change all six.</div><div><br></div><div>Anyway, I don't par=
ticularly have a particularly strong opinion on this one, as I rarely splic=
e lists together.=C2=A0 As long as it doesn't incur an extra bookkeepin=
g cost in the implementation of splice (other than returning an iterator it=
was already keeping track of) I wouldn't be against it.</div></div>-- =
<br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:ne=
vin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=
=A0 (847) 691-1404
</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 />
--047d7bae47b027113f0503c27775--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 23 Sep 2014 15:08:52 -0700
Raw View
--001a11c315261179db0503c2d0c8
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 23, 2014 at 2:43 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> On 23 September 2014 16:13, Jeremy T <jeremy8258@gmail.com> wrote:
>
>> *I. pop**
>> Most of the standard containers include one or more of pop(), pop_front(),
>> or pop_back(). All of these functions return type void. Personally, I
>> have never used one of these functions without preceding it with a call to
>> <container>.front() or <container>.back() to first obtain the element
>> I'm about to pop. Therefore, I propose that all of the pop* functions
>> have their signatures and logic changed to
>>
>> container::value_type pop*();
>>
>> Notice it returns a value rather than a reference or iterator. With move
>> semantics, such an operation is no longer expensive, and with RVO, the copy
>> (or move) would be avoided altogether.
>>
>
> Discussed (to death, IMNSHO) in the past. Breaking change, because your
> pop() can throw an exception, as well as more expensive for existing code,
> as that code would just throw away the return value even though internal to
> the container it must be copied/moved (even with RVO). One of the reasons
> for the back()/pop_back() split is because neither can throw, and you only
> pay the copying/moving cost if you need it. IMO extremely unlikely to
> pass. I'd vote strongly against it.
>
Has anyone proposed adding additional member signatures for this? LLVM's
containers have a pop_back_val() function in addition to pop_back() for
this (commonly-desired) functionality:
http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVectorImpl.html#a400eaca9881c8dcab97e9f42b1ab1815
> *II. Have std::[forward_]list::splice[_forward]() return an iterator*
>> Indeed, the above is the necessary method to perform such a task. Thus, I
>> propose that std::list::splice() return a similar value. Specifically,
>> that its declaration be changed to
>>
>> iterator splice (iterator position, list& x, iterator first, iterator
>> last);
>>
>> with its return value being "an iterator pointing to the element that
>> followed the last element in x transferred by the function call. This is
>> the container end if the operation transferred the last element in the
>> sequence."
>>
>
> std::list has six signatures for splice; I assume that you wish to change
> all six.
>
> Anyway, I don't particularly have a particularly strong opinion on this
> one, as I rarely splice lists together. As long as it doesn't incur an
> extra bookkeeping cost in the implementation of splice (other than
> returning an iterator it was already keeping track of) I wouldn't be
> against it.
> --
> 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/.
>
--
---
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/.
--001a11c315261179db0503c2d0c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Sep 23, 2014 at 2:43 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On =
23 September 2014 16:13, Jeremy T <span dir=3D"ltr"><<a href=3D"mailto:j=
eremy8258@gmail.com" target=3D"_blank">jeremy8258@gmail.com</a>></span> =
wrote:<br></span><div class=3D"gmail_extra"><div class=3D"gmail_quote"><spa=
n class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-=
style:solid;padding-left:1ex"><div dir=3D"ltr"><b>I. pop*</b><br>Most of th=
e standard containers include one or more of <span style=3D"color:rgb(0,0,2=
55)">pop()</span>, <span style=3D"color:rgb(0,0,255)">pop_front()</span>, o=
r <span style=3D"color:rgb(0,0,255)">pop_back()</span>. All of these functi=
ons return type <span style=3D"color:rgb(0,0,255)">void</span>. Personally,=
I have never used one of these functions without preceding it with a call =
to <span style=3D"color:rgb(0,0,255)"><container>.front()</span> or <=
span style=3D"color:rgb(0,0,255)"><container>.back()</span> to first =
obtain the element I'm about to pop. Therefore, I propose that all of t=
he <span style=3D"color:rgb(0,0,255)">pop*</span> functions have their sign=
atures and logic changed to<br><br><div style=3D"border:1px solid rgb(187,1=
87,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div>=
<span style=3D"color:rgb(0,0,0)">container</span><span style=3D"color:rgb(1=
02,102,0)">::</span><span style=3D"color:rgb(0,0,0)">value_type pop</span><=
span style=3D"color:rgb(102,102,0)">*();</span><span style=3D"color:rgb(0,0=
,0)"><br></span></div></code></div><br>Notice it returns a value rather tha=
n a reference or iterator. With move semantics, such an operation is no lon=
ger expensive, and with RVO, the copy (or move) would be avoided altogether=
..<br></div></blockquote><div><br></div></span><div>Discussed (to death, IMN=
SHO) in the past.=C2=A0 Breaking change, because your pop() can throw an ex=
ception, as well as more expensive for existing code, as that code would ju=
st throw away the return value even though internal to the container it mus=
t be copied/moved (even with RVO).=C2=A0 One of the reasons for the back()/=
pop_back() split is because neither can throw, and you only pay the copying=
/moving cost if you need it.=C2=A0 IMO extremely unlikely to pass.=C2=A0 I&=
#39;d vote strongly against it.</div></div></div></div></blockquote><div><b=
r></div><div>Has anyone proposed adding additional member signatures for th=
is? LLVM's containers have a pop_back_val() function in addition to pop=
_back() for this (commonly-desired) functionality:</div><div><br></div><div=
><a href=3D"http://llvm.org/docs/doxygen/html/classllvm_1_1SmallVectorImpl.=
html#a400eaca9881c8dcab97e9f42b1ab1815">http://llvm.org/docs/doxygen/html/c=
lassllvm_1_1SmallVectorImpl.html#a400eaca9881c8dcab97e9f42b1ab1815</a><br><=
/div><div>=C2=A0</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);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_extra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span=
class=3D""><b>II. Have std::[forward_]list::splice[_forward]() return an i=
terator</b><br></span><span class=3D"">Indeed, the above is the necessary m=
ethod to perform such a task. Thus, I propose that <span style=3D"color:rgb=
(0,0,255)">std::list::splice()</span> return a similar value. Specifically,=
that its declaration be changed to<br><br><div style=3D"border:1px solid r=
gb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><co=
de><div><span style=3D"color:rgb(0,0,0)">iterator splice </span><span style=
=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,0,0)">iterator=
position</span><span style=3D"color:rgb(102,102,0)">,</span><span style=3D=
"color:rgb(0,0,0)"> list</span><span style=3D"color:rgb(102,102,0)">&</=
span><span style=3D"color:rgb(0,0,0)"> x</span><span style=3D"color:rgb(102=
,102,0)">,</span><span style=3D"color:rgb(0,0,0)"> iterator first</span><sp=
an style=3D"color:rgb(102,102,0)">,</span><span style=3D"color:rgb(0,0,0)">=
iterator </span><span style=3D"color:rgb(0,0,136)">last</span><span style=
=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></s=
pan></div></code></div><br>with its return value being "an iterator po=
inting to the element that followed the last element <span style=3D"color:r=
gb(0,0,255)">in x</span> transferred by the function call. This is the cont=
ainer end if the operation transferred the last element in the sequence.&qu=
ot;<br></span></div></blockquote><div><br></div><div>std::list has six sign=
atures for splice; I assume that you wish to change all six.</div><div><br>=
</div><div>Anyway, I don't particularly have a particularly strong opin=
ion on this one, as I rarely splice lists together.=C2=A0 As long as it doe=
sn't incur an extra bookkeeping cost in the implementation of splice (o=
ther than returning an iterator it was already keeping track of) I wouldn&#=
39;t be against it.</div></div><span class=3D""><font color=3D"#888888">-- =
<br>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a href=3D"mailto:ne=
vin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>>=C2=
=A0 <a href=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_=
blank">(847) 691-1404</a>
</font></span></div></div><div class=3D""><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<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 />
--001a11c315261179db0503c2d0c8--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Tue, 23 Sep 2014 18:11:38 -0400
Raw View
--001a11c3c96cf18cf30503c2d973
Content-Type: text/plain; charset=UTF-8
On Tue, Sep 23, 2014 at 5:13 PM, Jeremy T <jeremy8258@gmail.com> wrote:
> Many container member functions return void instead of data or an
> iterator. While this makes sense in some cases, there are others where I
> believe the programmer would benefit greatly from a returned value. I
> intend for this thread to be a general discussion on this topic. However,
> I'd like to bring up two specific cases, namely the pop* functions, and
> std::list::splice().
>
> For any example given, changing the return type would of course modify
> current library headers. However, it wouldn't break any existing code, nor
> should it effect run-time efficiency due to return value optimization
> (RVO). Therefore, there would be minimal impact.
>
Due to SFINAE, almost any change can break existing code. But it would
hopefully be minimal. Also, I think taking a member-function-pointer to
pop(), or something like std::bind() might break (I think) due to return
type changes. Still minimal.
>
> *I. pop**
> Most of the standard containers include one or more of pop(), pop_front(),
> or pop_back(). All of these functions return type void. Personally, I
> have never used one of these functions without preceding it with a call to
> <container>.front() or <container>.back() to first obtain the element I'm
> about to pop. Therefore, I propose that all of the pop* functions have
> their signatures and logic changed to
>
> container::value_type pop*();
>
> Notice it returns a value rather than a reference or iterator. With move
> semantics, such an operation is no longer expensive, and with RVO, the copy
> (or move) would be avoided altogether.
>
>
Although others have mentioned that returning a value changes exception
behaviour, on the other hand, we need a better solution than front-then-pop
for lock-free data structures (where the pop and the access need to be one
atomic operation). Although the answer in those cases might need to be
something like
bool pop(value_type & val);
> *II. Have std::[forward_]list::splice[_forward]() return an iterator*
> The current signature of std::list::splice(), in its most verbose form, is
>
>
Did you say vector? Oh, list? OK, I don't care then. :-)
Tony
--
---
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/.
--001a11c3c96cf18cf30503c2d973
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Tue, Sep 23, 2014 at 5:13 PM, Jeremy T <span dir=3D"ltr"><<a href=
=3D"mailto:jeremy8258@gmail.com" target=3D"_blank">jeremy8258@gmail.com</a>=
></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Many =
container member functions return <span style=3D"color:rgb(0,0,255)">void</=
span> instead of data or an iterator. While this makes sense in some cases,=
there are others where I believe the programmer would benefit greatly from=
a returned value. I intend for this thread to be a general discussion on t=
his topic. However, I'd like to bring up two specific cases, namely the=
<span style=3D"color:rgb(0,0,255)">pop*</span> functions, and <span style=
=3D"color:rgb(0,0,255)">std::list::splice()</span>.<br><br>For any example =
given, changing the return type would of course modify current library head=
ers. However, it wouldn't break any existing code, nor should it effect=
run-time efficiency due to return value optimization (RVO). Therefore, the=
re would be minimal impact.<br></div></blockquote><div><br></div><div>Due t=
o SFINAE, almost any change can break existing code.=C2=A0 But it would hop=
efully be minimal.=C2=A0 Also, I think taking a member-function-pointer to =
pop(), or something like std::bind() might break (I think) due to return ty=
pe changes.=C2=A0 Still minimal.<br><br>=C2=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><br><b>I. pop*</b><br>Most of the standard c=
ontainers include one or more of <span style=3D"color:rgb(0,0,255)">pop()</=
span>, <span style=3D"color:rgb(0,0,255)">pop_front()</span>, or <span styl=
e=3D"color:rgb(0,0,255)">pop_back()</span>. All of these functions return t=
ype <span style=3D"color:rgb(0,0,255)">void</span>. Personally, I have neve=
r used one of these functions without preceding it with a call to <span sty=
le=3D"color:rgb(0,0,255)"><container>.front()</span> or <span style=
=3D"color:rgb(0,0,255)"><container>.back()</span> to first obtain the=
element I'm about to pop. Therefore, I propose that all of the <span s=
tyle=3D"color:rgb(0,0,255)">pop*</span> functions have their signatures and=
logic changed to<br><br><div style=3D"background-color:rgb(250,250,250);bo=
rder-color:rgb(187,187,187);border-style:solid;border-width:1px;word-wrap:b=
reak-word"><code><div><span style=3D"color:#000">container</span><span styl=
e=3D"color:#660">::</span><span style=3D"color:#000">value_type pop</span><=
span style=3D"color:#660">*();</span><span style=3D"color:#000"><br></span>=
</div></code></div><br>Notice it returns a value rather than a reference or=
iterator. With move semantics, such an operation is no longer expensive, a=
nd with RVO, the copy (or move) would be avoided altogether.<br><br></div><=
/blockquote><div><br></div><div>Although others have mentioned that returni=
ng a value changes exception behaviour, on the other hand, we need a better=
solution than front-then-pop for lock-free data structures (where the pop =
and the access need to be one atomic operation).=C2=A0 Although the answer =
in those cases might need to be something like<br><br></div><div>bool pop(v=
alue_type & val);<br><br></div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><b>II. Have std::[forward_]list::splice[_forward](=
) return an iterator</b><br>The current signature of <span style=3D"color:r=
gb(0,0,255)">std::list::splice()</span>, in its most verbose form, is<br><b=
r></div></blockquote><div><br></div><div>Did you say vector?=C2=A0 Oh, list=
?=C2=A0 OK, I don't care then. :-)<br></div></div><br></div><div class=
=3D"gmail_extra">Tony<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 />
--001a11c3c96cf18cf30503c2d973--
.
Author: Bjorn Reese <breese@mail1.stofanet.dk>
Date: Wed, 24 Sep 2014 11:54:34 +0200
Raw View
On 09/24/2014 12:11 AM, Tony V E wrote:
> Although others have mentioned that returning a value changes exception
> behaviour, on the other hand, we need a better solution than
> front-then-pop for lock-free data structures (where the pop and the
> access need to be one atomic operation). Although the answer in those
> cases might need to be something like
>
> bool pop(value_type & val);
Or maybe:
expected<value_type> pop();
if N4015 (or a successor) is accepted.
--
---
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/.
.