Topic: N3558 :A standardized representation of
Author: Xeo <hivemaster@hotmail.de>
Date: Fri, 24 May 2013 10:57:51 -0700 (PDT)
Raw View
------=_Part_721_28179192.1369418271199
Content-Type: text/plain; charset=ISO-8859-1
On Friday, May 24, 2013 7:07:20 PM UTC+2, Vicente J. Botet Escriba wrote:
>
> Hi,
>
> What is the rationale for when_all to return future<vector<future<R>>>
> instead of future<vector<R>>?
>
What is the rationale for when_any to return future<vector<future<R>>>
> instead of future<pair<size_t, R>> ?
>
Likely, proper exception propagation for both. For `when_any`, it's also
important that you get access to *all* passed futures, not just the one
that finished - this way, you don't have to keep the vector around yourself.
--
---
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/?hl=en.
------=_Part_721_28179192.1369418271199
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Friday, May 24, 2013 7:07:20 PM UTC+2, Vicente J. Botet Escriba wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div>
Hi, <br>
<br>
What is the rationale for when_all to return
future<vector<future<R>>> instead of
future<vector<R>>?<br></div></blockquote><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
What is the rationale for when_any to return
future<vector<future<R>>> instead of
future<pair<size_t, R>> ? <br></div></blockquote><div><br>L=
ikely, proper exception propagation for both. For `when_any`, it's also imp=
ortant that you get access to *all* passed futures, not just the one that f=
inished - this way, you don't have to keep the vector around yourself.</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_721_28179192.1369418271199--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 24 May 2013 21:02:39 +0200
Raw View
This is a multi-part message in MIME format.
--------------040602080006020708050402
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/05/13 19:57, Xeo a =E9crit :
> On Friday, May 24, 2013 7:07:20 PM UTC+2, Vicente J. Botet Escriba wrote:
>
> Hi,
>
> What is the rationale for when_all to return
> future<vector<future<R>>> instead of future<vector<R>>?
>
> What is the rationale for when_any to return
> future<vector<future<R>>> instead of future<pair<size_t, R>> ?
>
>
> Likely, proper exception propagation for both.
Oh, I see. No body has the need to get just: the vector of values when=20
no exception has been thrown or an exception when at least one exception=20
has been thrown?
> For `when_any`, it's also important that you get access to *all*=20
> passed futures, not just the one that finished - this way, you don't=20
> have to keep the vector around yourself.
>
I understand what this solves. The drawback is that we need to to=20
iterate over the vector of futures when the when_any function could know=20
about the index of the future on the vector.
Returning future<pair<size_t, vector<future<R>>>> would provide=20
efficiency and safety.
Vicente
--=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/?hl=3Den.
--------------040602080006020708050402
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 24/05/13 19:57, Xeo a écrit :<br>
</div>
<blockquote
cite="mid:c959abc7-55a0-4a6a-9b20-9752cbe63af0@isocpp.org"
type="cite">On Friday, May 24, 2013 7:07:20 PM UTC+2, Vicente J.
Botet Escriba wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div> Hi, <br>
<br>
What is the rationale for when_all to return
future<vector<future<R>>> instead of
future<vector<R>>?<br>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000"> What is the rationale for
when_any to return future<vector<future<R>>>
instead of future<pair<size_t, R>> ? <br>
</div>
</blockquote>
<div><br>
Likely, proper exception propagation for both. </div>
</blockquote>
Oh, I see. No body has the need to get just: the vector of values
when no exception has been thrown or an exception when at least one
exception has been thrown?<br>
<blockquote
cite="mid:c959abc7-55a0-4a6a-9b20-9752cbe63af0@isocpp.org"
type="cite">
<div>For `when_any`, it's also important that you get access to
*all* passed futures, not just the one that finished - this way,
you don't have to keep the vector around yourself.</div>
<br>
</blockquote>
I understand what this solves. The drawback is that we need to to
iterate over the vector of futures when the when_any function could
know about the index of the future on the vector. <br>
Returning future<pair<size_t,
vector<future<R>>>> would provide efficiency and
safety.<br>
<br>
Vicente<br>
</body>
</html>
<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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------040602080006020708050402--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 24 May 2013 16:46:58 -0300
Raw View
--001a11c34f4043fb9004dd7c1208
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, May 24, 2013 at 4:02 PM, Vicente J. Botet Escriba <
vicente.botet@wanadoo.fr> wrote:
> Le 24/05/13 19:57, Xeo a =E9crit :
>
> On Friday, May 24, 2013 7:07:20 PM UTC+2, Vicente J. Botet Escriba wrote:
>>
>> Hi,
>>
>> What is the rationale for when_all to return future<vector<future<R>>>
>> instead of future<vector<R>>?
>>
> What is the rationale for when_any to return future<vector<future<R>>>
>> instead of future<pair<size_t, R>> ?
>>
>
> Likely, proper exception propagation for both.
>
> Oh, I see. No body has the need to get just: the vector of values when no
> exception has been thrown or an exception when at least one exception has
> been thrown?
>
> For `when_any`, it's also important that you get access to *all* passed
> futures, not just the one that finished - this way, you don't have to kee=
p
> the vector around yourself.
>
> I understand what this solves. The drawback is that we need to to iterat=
e
> over the vector of futures when the when_any function could know about th=
e
> index of the future on the vector.
> Returning future<pair<size_t, vector<future<R>>>> would provide efficienc=
y
> and safety.
>
> What if you had more than one simultaneous result?
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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/?hl=3Den.
--001a11c34f4043fb9004dd7c1208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 24, 2013 at 4:02 PM, Vicente J. Botet Escriba <span dir=3D"ltr"><=
;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bote=
t@wanadoo.fr</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
<div>Le 24/05/13 19:57, Xeo a =E9crit=A0:<br>
</div><div class=3D"im">
<blockquote type=3D"cite">On Friday, May 24, 2013 7:07:20 PM UTC+2, Vic=
ente J.
Botet Escriba wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div> Hi, <br>
<br>
What is the rationale for when_all to return
future<vector<future<R>>> instead of=A0
future<vector<R>>?<br>
</div>
</blockquote>
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor=3D"#FFFFFF" text=3D"#000000"> What is the rationale fo=
r
when_any to return future<vector<future<R>>>
instead of future<pair<size_t, R>> ? <br>
</div>
</blockquote>
<div><br>
Likely, proper exception propagation for both. </div>
</blockquote></div>
Oh, I see. No body has the need to get just: the vector of values
when no exception has been thrown or an exception when at least one
exception has been thrown?<div class=3D"im"><br>
<blockquote type=3D"cite">
<div>For `when_any`, it's also important that you get access to
*all* passed futures, not just the one that finished - this way,
you don't have to keep the vector around yourself.</div>
<br>
</blockquote></div>
I understand what this solves. The drawback is that we need to to
iterate over the vector of futures when the when_any function could
know about the index of the future on the vector. <br>
Returning future<pair<size_t,
vector<future<R>>>> would provide efficiency and
safety.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br></font></span></div></blockquote><div>What if you had more than one=
simultaneous result?<br></div></div><br clear=3D"all"><br>-- <br>Fernando =
Cacciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-co=
nsulting.com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--001a11c34f4043fb9004dd7c1208--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 24 May 2013 23:07:43 +0300
Raw View
--001a11c1cffc0e703104dd7c5ae0
Content-Type: text/plain; charset=ISO-8859-1
On 24 May 2013 22:46, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> I understand what this solves. The drawback is that we need to to iterate
> over the vector of futures when the when_any function could know about the
> index of the future on the vector.
>
>> Returning future<pair<size_t, vector<future<R>>>> would provide
>> efficiency and safety.
>>
>> What if you had more than one simultaneous result?
>
>
Then the size_t gives you the one that was noticed first, and the rest are
still in the vector?
--
---
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/?hl=en.
--001a11c1cffc0e703104dd7c5ae0
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 24 May 2013 22:46, Fernando Cacciola <span dir="ltr"><<a href="mailto:fernando.cacciola@gmail.com" target="_blank">fernando.cacciola@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">I understand what this solves. The drawback is that we need to to
iterate over the vector of futures when the when_any function could
know about the index of the future on the vector. <br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Returning future<pair<size_t,
vector<future<R>>>> would provide efficiency and
safety.<span><font color="#888888"><br>
<br></font></span></div></blockquote></div><div>What if you had more than one simultaneous result?<span class="HOEnZb"><font color="#888888"><br></font></span></div></div><span class="HOEnZb"><font color="#888888"><br>
</font></span></div></div></blockquote><div><br></div><div>Then the size_t gives you the one that was noticed first, and the rest are still in the vector? <br></div></div><br></div></div>
<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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--001a11c1cffc0e703104dd7c5ae0--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 24 May 2013 17:16:31 -0300
Raw View
--047d7bf0c5bee76d9504dd7c7b48
Content-Type: text/plain; charset=ISO-8859-1
On Fri, May 24, 2013 at 5:07 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
>
>
>
> On 24 May 2013 22:46, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>
>> I understand what this solves. The drawback is that we need to to iterate
>> over the vector of futures when the when_any function could know about the
>> index of the future on the vector.
>>
>>> Returning future<pair<size_t, vector<future<R>>>> would provide
>>> efficiency and safety.
>>>
>>> What if you had more than one simultaneous result?
>>
>>
> Then the size_t gives you the one that was noticed first, and the rest are
> still in the vector?
>
> But you would not know if you got just one result, so you would
nonetheless scan the whole vector just the same.
future<pair<vector<size_t>,vector<future<R>>>> would fix that, but it's
getting complex.
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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/?hl=en.
--047d7bf0c5bee76d9504dd7c7b48
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 24, 2013 at 5:07 PM, Ville Voutilainen <span dir=3D"ltr"><<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 24 May 2013 22:=
46, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacc=
iola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</a>></span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>I understand what this solves. The drawback=
is that we need to to
iterate over the vector of futures when the when_any function could
know about the index of the future on the vector. <br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
Returning future<pair<size_t,
vector<future<R>>>> would provide efficiency and
safety.<span><font color=3D"#888888"><br>
<br></font></span></div></blockquote></div><div>What if you had more th=
an one simultaneous result?<span><font color=3D"#888888"><br></font></span>=
</div></div><span><font color=3D"#888888"><br>
</font></span></div></div></blockquote><div><br></div></div><div>Then the s=
ize_t gives you the one that was noticed first, and the rest are still in t=
he vector? <br></div></div><br></div></div></blockquote><div>But you would =
not know if you got just one result, so you would nonetheless scan the whol=
e vector just the same.<br>
<br></div><div>future<pair<vector<size_t>,vector<future<R=
>>>> would fix that, but it's getting complex.<br clear=3D"=
all"></div></div><br>-- <br>Fernando Cacciola<br>SciSoft Consulting, Founde=
r<br>
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7bf0c5bee76d9504dd7c7b48--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Fri, 24 May 2013 17:19:55 -0300
Raw View
--14dae93d8eac19a04c04dd7c88cc
Content-Type: text/plain; charset=ISO-8859-1
On Fri, May 24, 2013 at 5:16 PM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:
> On Fri, May 24, 2013 at 5:07 PM, Ville Voutilainen <
> ville.voutilainen@gmail.com> wrote:
>
>>
>>
>>
>> On 24 May 2013 22:46, Fernando Cacciola <fernando.cacciola@gmail.com>wrote:
>>
>>> I understand what this solves. The drawback is that we need to to
>>> iterate over the vector of futures when the when_any function could know
>>> about the index of the future on the vector.
>>>
>>>> Returning future<pair<size_t, vector<future<R>>>> would provide
>>>> efficiency and safety.
>>>>
>>>> What if you had more than one simultaneous result?
>>>
>>>
>> Then the size_t gives you the one that was noticed first, and the rest
>> are still in the vector?
>>
>> But you would not know if you got just one result, so you would
> nonetheless scan the whole vector just the same.
>
> future<pair<vector<size_t>,vector<future<R>>>> would fix that, but it's
> getting complex.
>
> Scratch that.
The implementation would notice *only one* first so it can return that one
right away (and like you said the rest are still in the vector)
-
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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/?hl=en.
--14dae93d8eac19a04c04dd7c88cc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, May 24, 2013 at 5:16 PM, Fernando Cacciola <span dir=3D"ltr"><<a hre=
f=3D"mailto:fernando.cacciola@gmail.com" target=3D"_blank">fernando.cacciol=
a@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Fri, May 24, 2013 at 5:07 P=
M, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville.voutilai=
nen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>></span>=
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div>On 24 May 2013 22:46, Fernando =
Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernando.cacciola@gmail.co=
m" target=3D"_blank">fernando.cacciola@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div>I understand what this solves. The drawback=
is that we need to to
iterate over the vector of futures when the when_any function could
know about the index of the future on the vector. <br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div bgcolor=3D"#FFFFFF" text=3D"#000000">
Returning future<pair<size_t,
vector<future<R>>>> would provide efficiency and
safety.<span><font color=3D"#888888"><br>
<br></font></span></div></blockquote></div><div>What if you had more th=
an one simultaneous result?<span><font color=3D"#888888"><br></font></span>=
</div></div><span><font color=3D"#888888"><br>
</font></span></div></div></blockquote><div><br></div></div><div>Then the s=
ize_t gives you the one that was noticed first, and the rest are still in t=
he vector? <br></div></div><br></div></div></blockquote></div><div>But you =
would not know if you got just one result, so you would nonetheless scan th=
e whole vector just the same.<br>
<br></div><div>future<pair<vector<size_t>,vector<future<R=
>>>> would fix that, but it's getting complex.<br clear=3D"=
all"></div></div><div class=3D"im"><br></div></div></div></blockquote><div>
Scratch that.<br><br></div><div>The implementation would notice *only one* =
first so it can return that one right away (and like you said the rest are =
still in the vector)<br><br></div></div>- <br>Fernando Cacciola<br>SciSoft =
Consulting, Founder<br>
<a href=3D"http://www.scisoft-consulting.com">http://www.scisoft-consulting=
..com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--14dae93d8eac19a04c04dd7c88cc--
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 24 May 2013 15:24:20 -0500
Raw View
--0023543329e6e6a12204dd7c9718
Content-Type: text/plain; charset=ISO-8859-1
On 24 May 2013 14:02, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>wrote:
>
> Returning future<pair<size_t, vector<future<R>>>> would provide efficiency
> and safety.
>
If you are going to go this route, please don't use pair. It is much
better to have field names that mean something.
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/?hl=en.
--0023543329e6e6a12204dd7c9718
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 24 May 2013 14:02, Vicente J. Botet Escriba <span dir=3D"ltr"><<a hre=
f=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.botet@wanad=
oo.fr</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;padd=
ing-left:1ex">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000"><br>
Returning future<pair<size_t,
vector<future<R>>>> would provide efficiency and
safety.<span class=3D"HOEnZb"></span><br></div></blockquote></div><br c=
lear=3D"all">If you are going to go this route, please don't use pair.=
=A0 It is much better to have field names that mean something.<br>=A0Nevin =
":-)" Liber=A0 <mailto:<a href=3D"mailto:nevin@eviloverlord.co=
m" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--0023543329e6e6a12204dd7c9718--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 25 May 2013 14:25:18 +0200
Raw View
This is a multi-part message in MIME format.
--------------030901000208050905050609
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/05/13 22:24, Nevin Liber a =E9crit :
> On 24 May 2013 14:02, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
>
> Returning future<pair<size_t, vector<future<R>>>> would provide
> efficiency and safety.
>
>
> If you are going to go this route, please don't use pair. It is much=20
> better to have field names that mean something.
I agree that using accessors would be more readable, hide the=20
representation and in addition it could provide a value function that=20
would retrieve the first value set. The quiz would be to find a name for=20
the class providing these accessors ;-) Any suggestion is welcome.
template <typename R>
class ???
{
public:
vector<future<R> vector() && noexcept;
R value() &;
};
auto f =3D when_any(f1, f2);
....
int i =3D f.get().value(); // efficiency
vector<future<R> v =3D f.get().vector(); // safety
The following is safe as the futures are transfered to the new variable
auto f =3D when_any(f1, f2).to_vector();
But should the following compile
int i =3D when_any(f1, f2).value();
With the following declaration the preceding statement must fail at=20
compile time, isn't it?
R value() &;
Vicente
--=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/?hl=3Den.
--------------030901000208050905050609
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 24/05/13 22:24, Nevin Liber a
écrit :<br>
</div>
<blockquote
cite="mid:CAGg_6+N60LQLUXvkzY_4-8=-OuBQ-s+n4GttmNTKm7VMc8vfuA@mail.gmail.com"
type="cite">On 24 May 2013 14:02, Vicente J. Botet Escriba <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:vicente.botet@wanadoo.fr" target="_blank">vicente.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><br>
Returning future<pair<size_t,
vector<future<R>>>> would provide
efficiency and safety.<span class="HOEnZb"></span><br>
</div>
</blockquote>
</div>
<br clear="all">
If you are going to go this route, please don't use pair. It is
much better to have field names that mean something.<br>
</blockquote>
<br>
I agree that using accessors would be more readable, hide the
representation and in addition it could provide a value function
that would retrieve the first value set. The quiz would be to find a
name for the class providing these accessors ;-) Any suggestion is
welcome.<br>
<br>
template <typename R><br>
class ???<br>
{<br>
public:<br>
vector<future<R> vector() && noexcept;<br>
R value() &;<br>
};<br>
<br>
auto f = when_any(f1, f2);<br>
...<br>
int i = f.get().value(); // efficiency<br>
vector<future<R> v = f.get().vector(); // safety<br>
<br>
The following is safe as the futures are transfered to the new
variable<br>
auto f = when_any(f1, f2).to_vector();<br>
<br>
But should the following compile<br>
int i = when_any(f1, f2).value();<br>
<br>
With the following declaration the preceding statement must fail at
compile time, isn't it?<br>
R value() &;<br>
<br>
Vicente<br>
</body>
</html>
<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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------030901000208050905050609--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 25 May 2013 15:08:19 +0200
Raw View
This is a multi-part message in MIME format.
--------------020701010008060109080707
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 24/05/13 19:07, Vicente J. Botet Escriba a =E9crit :
> Hi,
>
> What is the rationale for when_all to return future<vector<future<R>>>=20
> instead of future<vector<R>>?
> What is the rationale for when_any to return future<vector<future<R>>>=20
> instead of future<pair<size_t, R>> ?
>
>
I have one more question about when_any. What would be the expected=20
behavior when when_any has parameters that shared the same shared state,=20
as in
std::shared_future<int> fi1 =3D=20
std::async(calculate_the_answer_to_life_the_universe_and_everything).share(=
);
std::shared_future<int> fi2 =3D fi1;
std::when_any(fi1, fi2).wait();
Vicente
--=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/?hl=3Den.
--------------020701010008060109080707
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 24/05/13 19:07, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:519F9E48.7050700@wanadoo.fr" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hi, <br>
<br>
What is the rationale for when_all to return
future<vector<future<R>>> instead of
future<vector<R>>? <br>
What is the rationale for when_any to return
future<vector<future<R>>> instead of
future<pair<size_t, R>> ? <br>
<br>
<br>
</blockquote>
I have one more question about when_any. What would be the expected
behavior when when_any has parameters that shared the same shared
state, as in<br>
<br>
std::shared_future<int> fi1 =
std::async(calculate_the_answer_to_life_the_universe_and_everything).share();<br>
std::shared_future<int> fi2 = fi1;<br>
std::when_any(fi1, fi2).wait();<br>
<br>
Vicente<br>
<br>
</body>
</html>
<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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------020701010008060109080707--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 30 May 2013 08:21:26 +0200
Raw View
This is a multi-part message in MIME format.
--------------070705060804030208090906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 25/05/13 15:08, Vicente J. Botet Escriba a =E9crit :
> Le 24/05/13 19:07, Vicente J. Botet Escriba a =E9crit :
>> Hi,
>>
>> What is the rationale for when_all to return=20
>> future<vector<future<R>>> instead of future<vector<R>>?
>> What is the rationale for when_any to return=20
>> future<vector<future<R>>> instead of future<pair<size_t, R>> ?
>>
>>
> I have one more question about when_any. What would be the expected=20
> behavior when when_any has parameters that shared the same shared=20
> state, as in
>
> std::shared_future<int> fi1 =3D=20
> std::async(calculate_the_answer_to_life_the_universe_and_everything).shar=
e();
> std::shared_future<int> fi2 =3D fi1;
> std::when_any(fi1, fi2).wait();
>
Or even this radical one
std::future<int> fi1 =3D=20
std::async(calculate_the_answer_to_life_the_universe_and_everything).share(=
);
std::when_any(fi1, fi1).wait();
Best,
Vicente
--=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/?hl=3Den.
--------------070705060804030208090906
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 25/05/13 15:08, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:51A0B7C3.40109@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 24/05/13 19:07, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:519F9E48.7050700@wanadoo.fr" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
Hi, <br>
<br>
What is the rationale for when_all to return
future<vector<future<R>>> instead of
future<vector<R>>? <br>
What is the rationale for when_any to return
future<vector<future<R>>> instead of
future<pair<size_t, R>> ? <br>
<br>
<br>
</blockquote>
I have one more question about when_any. What would be the
expected behavior when when_any has parameters that shared the
same shared state, as in<br>
<br>
std::shared_future<int> fi1 =
std::async(calculate_the_answer_to_life_the_universe_and_everything).share();<br>
std::shared_future<int> fi2 = fi1;<br>
std::when_any(fi1, fi2).wait();<br>
<br>
</blockquote>
Or even this radical one<br>
<br>
std::future<int> fi1 =
std::async(calculate_the_answer_to_life_the_universe_and_everything).share();<br>
std::when_any(fi1, fi1).wait();<br>
<br>
Best,<br>
Vicente<br>
</body>
</html>
<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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------070705060804030208090906--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 30 May 2013 08:22:37 +0200
Raw View
This is a multi-part message in MIME format.
--------------030302040001070303020701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 25/05/13 14:25, Vicente J. Botet Escriba a =E9crit :
> Le 24/05/13 22:24, Nevin Liber a =E9crit :
>> On 24 May 2013 14:02, Vicente J. Botet Escriba=20
>> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>>
>>
>> Returning future<pair<size_t, vector<future<R>>>> would provide
>> efficiency and safety.
>>
>>
>> If you are going to go this route, please don't use pair. It is much=20
>> better to have field names that mean something.
>
> I agree that using accessors would be more readable, hide the=20
> representation and in addition it could provide a value function that=20
> would retrieve the first value set. The quiz would be to find a name=20
> for the class providing these accessors ;-) Any suggestion is welcome.
>
> template <typename R>
> class ???
> {
> public:
> vector<future<R> vector() && noexcept;
> R value() &;
> };
>
> auto f =3D when_any(f1, f2);
> ...
> int i =3D f.get().value(); // efficiency
> vector<future<R> v =3D f.get().vector(); // safety
>
> The following is safe as the futures are transfered to the new variable
> auto f =3D when_any(f1, f2).to_vector();
>
> But should the following compile
> int i =3D when_any(f1, f2).value();
>
> With the following declaration the preceding statement must fail at=20
> compile time, isn't it?
> R value() &;
>
>
Any comments from the authors?
Vicente
--=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/?hl=3Den.
--------------030302040001070303020701
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 25/05/13 14:25, Vicente J. Botet
Escriba a écrit :<br>
</div>
<blockquote cite="mid:51A0ADAE.5030908@wanadoo.fr" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Le 24/05/13 22:24, Nevin Liber a
écrit :<br>
</div>
<blockquote
cite="mid:CAGg_6+N60LQLUXvkzY_4-8=-OuBQ-s+n4GttmNTKm7VMc8vfuA@mail.gmail.com"
type="cite">On 24 May 2013 14:02, Vicente J. Botet Escriba <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:vicente.botet@wanadoo.fr" target="_blank">vicente.botet@wanadoo.fr</a>></span>
wrote:<br>
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><br>
Returning future<pair<size_t,
vector<future<R>>>> would provide
efficiency and safety.<span class="HOEnZb"></span><br>
</div>
</blockquote>
</div>
<br clear="all">
If you are going to go this route, please don't use pair. It is
much better to have field names that mean something.<br>
</blockquote>
<br>
I agree that using accessors would be more readable, hide the
representation and in addition it could provide a value function
that would retrieve the first value set. The quiz would be to find
a name for the class providing these accessors ;-) Any suggestion
is welcome.<br>
<br>
template <typename R><br>
class ???<br>
{<br>
public:<br>
vector<future<R> vector() && noexcept;<br>
R value() &;<br>
};<br>
<br>
auto f = when_any(f1, f2);<br>
...<br>
int i = f.get().value(); // efficiency<br>
vector<future<R> v = f.get().vector(); // safety<br>
<br>
The following is safe as the futures are transfered to the new
variable<br>
auto f = when_any(f1, f2).to_vector();<br>
<br>
But should the following compile<br>
int i = when_any(f1, f2).value();<br>
<br>
With the following declaration the preceding statement must fail
at compile time, isn't it?<br>
R value() &;<br>
<br>
<br>
</blockquote>
Any comments from the authors?<br>
<br>
Vicente<br>
</body>
</html>
<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/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------030302040001070303020701--
.
Author: Anthony Williams <anthony.ajw@gmail.com>
Date: Thu, 30 May 2013 08:45:35 +0100
Raw View
On 30/05/13 07:21, Vicente J. Botet Escriba wrote:
> Le 25/05/13 15:08, Vicente J. Botet Escriba a =E9crit :
>> Le 24/05/13 19:07, Vicente J. Botet Escriba a =E9crit :
>>> Hi,
>>>
>>> What is the rationale for when_all to return
>>> future<vector<future<R>>> instead of future<vector<R>>?
>>> What is the rationale for when_any to return
>>> future<vector<future<R>>> instead of future<pair<size_t, R>> ?
>>>
>>>
>> I have one more question about when_any. What would be the expected
>> behavior when when_any has parameters that shared the same shared
>> state, as in
>>
>> std::shared_future<int> fi1 =3D
>> std::async(calculate_the_answer_to_life_the_universe_and_everything).sha=
re();
>> std::shared_future<int> fi2 =3D fi1;
>> std::when_any(fi1, fi2).wait();
>>
This will wait until the async finishes. Both futures become ready
together, so there is no problem here.
> Or even this radical one
>=20
> std::future<int> fi1 =3D
> std::async(calculate_the_answer_to_life_the_universe_and_everything).shar=
e();
> std::when_any(fi1, fi1).wait();
This shouldn't compile, since fi1 is not copyable, so you should have to
move it into the when_any call.
Under the current spec, the interface allows it to compile, but it may
fail due to internal implementation details, in which case the spec
needs updating.
If it did compile then I would expect it to complain about an invalid
future, since after moving the first arg the second one will be empty.
Anthony
--=20
Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/
just::thread C++11 thread library http://www.stdthread.co.uk
Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976
--=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/?hl=3Den.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 30 May 2013 22:11:29 +0200
Raw View
Le 30/05/13 09:45, Anthony Williams a =E9crit :
> On 30/05/13 07:21, Vicente J. Botet Escriba wrote:
>> Le 25/05/13 15:08, Vicente J. Botet Escriba a =E9crit :
>>> Le 24/05/13 19:07, Vicente J. Botet Escriba a =E9crit :
>>>> Hi,
>>>>
>>>> What is the rationale for when_all to return
>>>> future<vector<future<R>>> instead of future<vector<R>>?
>>>> What is the rationale for when_any to return
>>>> future<vector<future<R>>> instead of future<pair<size_t, R>> ?
>>>>
>>>>
>>> I have one more question about when_any. What would be the expected
>>> behavior when when_any has parameters that shared the same shared
>>> state, as in
>>>
>>> std::shared_future<int> fi1 =3D
>>> std::async(calculate_the_answer_to_life_the_universe_and_everything).sh=
are();
>>> std::shared_future<int> fi2 =3D fi1;
>>> std::when_any(fi1, fi2).wait();
>>>
> This will wait until the async finishes. Both futures become ready
> together, so there is no problem here.
Shouldn't the wait function synchronize with the each one of the=20
futures? I was thinking here to the implementation of=20
boost:;wait_for_any which locks all the future shared state mutex, and=20
deadlocks as the same mutex is locked twice.
>
>> Or even this radical one
>>
>> std::future<int> fi1 =3D
>> std::async(calculate_the_answer_to_life_the_universe_and_everything).sha=
re();
>> std::when_any(fi1, fi1).wait();
> This shouldn't compile, since fi1 is not copyable, so you should have to
> move it into the when_any call.
Of course. My bad, I was using it as boost::wait_for_any which takes the=20
futures by reference.
>
> Under the current spec, the interface allows it to compile,
I'm lost. Do you mean after moving it?
std::when_any(move(fi1), move(fi1)).wait();
Vicente
> but it may
> fail due to internal implementation details, in which case the spec
> needs updating.
>
> If it did compile then I would expect it to complain about an invalid
> future, since after moving the first arg the second one will be empty.
>
> Anthony
--=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/?hl=3Den.
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 07 Jun 2013 21:22:29 +0200
Raw View
Le 30/05/13 09:45, Anthony Williams a =E9crit :
> On 30/05/13 07:21, Vicente J. Botet Escriba wrote:
>> Le 25/05/13 15:08, Vicente J. Botet Escriba a =E9crit :
>>> Le 24/05/13 19:07, Vicente J. Botet Escriba a =E9crit :
>>>> Hi,
>>>>
>>>> What is the rationale for when_all to return
>>>> future<vector<future<R>>> instead of future<vector<R>>?
>>>> What is the rationale for when_any to return
>>>> future<vector<future<R>>> instead of future<pair<size_t, R>> ?
>>>>
>>>>
>>> I have one more question about when_any. What would be the expected
>>> behavior when when_any has parameters that shared the same shared
>>> state, as in
>>>
>>> std::shared_future<int> fi1 =3D
>>> std::async(calculate_the_answer_to_life_the_universe_and_everything).sh=
are();
>>> std::shared_future<int> fi2 =3D fi1;
>>> std::when_any(fi1, fi2).wait();
>>>
> This will wait until the async finishes. Both futures become ready
> together, so there is no problem here.
>
Any other point of view?
Vicente
--=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/?hl=3Den.
.