Topic: N3558 : more asynchronous operation


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Fri, 24 May 2013 19:30:10 +0200
Raw View
This is a multi-part message in MIME format.
--------------080006030006090002050902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Hi,
is there an interest in an evolution of the functionality of=20
std::future/std::shared_future that complements the proposal "N3558 A=20
standardized representation of Asynchronous operations" with more=20
observers and factories mainly based on the split between futures having=20
a value or a exception.

*.has_value()*and*  .has_exception():*

These two observers have the same "raison d'=EAtre" than the ready()=20
function proposed in [1] respect to the function .then(), but in this=20
case respect to the functions .when_valued() and .when_exceptional()=20
respectively.

*.get_or():*

Quite often the user as a fallback value that should be used when the=20
future has an exception.

And the following future factories

*.when_valued(f)*and*  .when_exceptional(f):*

These functions behave like .then() but will call the continuation only=20
when the future is ready with a value or an exception respectively. The=20
continuations takes the future value type or an exception_ptr as=20
parameter respectively.

*.fallback_to(v):*

Quite often the user as a fallback value that should be used when the=20
future has an exception. This factory creates a new future that will=20
fallback to the parameter if the source future will be ready with an=20
exception. The following

   f.fallback_to(v);

is is a thread safe shortcut for

   f.then([](future<T> f) {
     if (f.has_value() return f.get()
     else return v;
   })

*make_valued_future(v)*and*  make_exceptional_future(e):*

I think that the case for functions that know that an exception must be=20
thrown at the point of construction are as often than the ones that know=20
the value. In both cases the result is know immediately but must be=20
returned as future. By using make_valued_future and=20
make_exceptional_future a future can be created which hold a precomputed=20
result of its shared state.

Alternatively the member function factories could be non-member function.

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.



--------------080006030006090002050902
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi, <br>
    is there an interest in an evolution of the functionality of
    std::future/std::shared_future that complements the proposal <span
      lang="en-US">&#8220;N3558
      A standardized representation of Asynchronous operations&#8221; with
      more observers and factories mainly based on the split between
      futures having a value or a exception.</span>
    <br>
    <title></title>
    <meta name="GENERATOR" content="OpenOffice.org 3.3 (Unix)">
    <style type="text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->
 </style>
    <pre><b>.has_value() </b>and<b> .has_exception():</b></pre>
    <p>
      These two observers have the same &#8220;raison d'&ecirc;tre&#8221; than the
      ready() function proposed in [1] respect to the function .then(),
      but
      in this case respect to the functions .when_valued() and
      .when_exceptional() respectively.</p>
    <pre><b>.get_or():</b>
</pre>
    Quite often the user as a fallback value that should be used when
    the
    future has an exception.<br>
    <p>And the following future factories</p>
    <pre><b>.when_valued(f) </b>and<b> .when_exceptional(f):</b></pre>
    <p>
      These functions behave like .then() but will call the continuation
      only when the future is ready with a value or an exception
      respectively. The continuations takes the future value type or an
      exception_ptr as parameter respectively.</p>
    <pre><b>.fallback_to(v):</b></pre>
    <p style="font-weight: normal">
      Quite often the user as a fallback value that should be used when
      the
      future has an exception. This factory creates a new future that
      will
      fallback to the parameter if the source future will be ready with
      an
      exception. The following </p>
    <pre>  f.fallback_to(v);
</pre>
    <p style="font-weight: normal">
      is is a thread safe shortcut for </p>
    <pre>  f.then([](future&lt;T&gt; f) {
    if (f.has_value() return f.get()
    else return v;
  })

<b>make_valued_future(v) </b>and<b> make_exceptional_future(e):</b></pre>
    <p>
      I think that the case for functions that know that an exception
      must
      be thrown at the point of construction are as often than the ones
      that know the value. In both cases the result is know immediately
      but must be returned as future. By using make_valued_future and
      make_exceptional_future a future can be created which hold a
      precomputed result of its shared state.<br>
    </p>
    <p>Alternatively the member function factories could be non-member
      function.<br>
    </p>
    <p>Best,<br>
      Vicente<br>
    </p>
    <title></title>
    <meta name="GENERATOR" content="OpenOffice.org 3.3 (Unix)">
    <style type="text/css">
 <!--
  @page { margin: 2cm }
  P { margin-bottom: 0.21cm }
 -->
 </style>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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 />
&nbsp;<br />
&nbsp;<br />

--------------080006030006090002050902--

.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 25 May 2013 13:49:15 +0200
Raw View
This is a multi-part message in MIME format.
--------------000505080509050903040901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 24/05/13 19:30, Vicente J. Botet Escriba a =E9crit :
> *make_valued_future(v) *and*make_exceptional_future(e):*
>
> I think that the case for functions that know that an exception must=20
> be thrown at the point of construction are as often than the ones that=20
> know the value. In both cases the result is know immediately but must=20
> be returned as future. By using make_valued_future and=20
> make_exceptional_future a future can be created which hold a=20
> precomputed result of its shared state.
>
>
Please forget the names proposed. There is no need to have two different=20
functions, the same name can be used to create valued and exceptional=20
futures

     template <typename T>
     future<typename decay<T>::type> make_ready_future(T&& value);
     future<void> make_ready_future();
     template <typename T>
     future<T> make_ready_future(exception_ptr ex);
     template <typename T, typename E>
     future<T> make_ready_future(E ex);


std::future<int> compute(int x)
{
   if (x < 0) return=20
std::make_ready_future*<int>*(*std::logic_error("Error")*); // error=20
condition
   if (x =3D=3D 0) return std::make_ready_future(0); // immediate result
   std::future<int> f1 =3D std::async([]() { return x+1; }); //=20
asynchronous result
   return std::move(f1);
}

Would this addition acceptable?

BTW, what was the rationale to provide only this single overload to=20
std::promise
   void promise<R>::set_exception(exception_ptr p);

Why not adding
   template <typename E>
   void promise<R>::set_exception(E p);

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.



--------------000505080509050903040901
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:30, Vicente J. Botet
      Escriba a &eacute;crit&nbsp;:<br>
    </div>
    <blockquote cite="mid:519FA3A2.8040905@wanadoo.fr" type="cite">
      <meta http-equiv="content-type" content="text/html;
        charset=ISO-8859-1">
      <b>make_valued_future(v) </b>and<b> make_exceptional_future(e):</b>
      <p> I think that the case for functions that know that an
        exception must be thrown at the point of construction are as
        often than the ones that know the value. In both cases the
        result is know immediately but must be returned as future. By
        using make_valued_future and make_exceptional_future a future
        can be created which hold a precomputed result of its shared
        state.<br>
      </p>
      <br>
    </blockquote>
    Please forget the names proposed. There is no need to have two
    different functions, the same name can be used to create valued and
    exceptional futures<br>
    <br>
    &nbsp;&nbsp;&nbsp; template &lt;typename T&gt;<br>
    &nbsp;&nbsp;&nbsp; future&lt;typename decay&lt;T&gt;::type&gt;
    make_ready_future(T&amp;&amp; value);<br>
    &nbsp;&nbsp;&nbsp; future&lt;void&gt; make_ready_future();<br>
    &nbsp;&nbsp;&nbsp; template &lt;typename T&gt;<br>
    &nbsp;&nbsp;&nbsp; future&lt;T&gt; make_ready_future(exception_ptr ex);<br>
    &nbsp;&nbsp;&nbsp; template &lt;typename T, typename E&gt;<br>
    &nbsp;&nbsp;&nbsp; future&lt;T&gt; make_ready_future(E ex);<br>
    <br>
    <br>
    std::future&lt;int&gt; compute(int x)<br>
    {<br>
    &nbsp; if (x &lt; 0) return std::make_ready_future<big><big><b>&lt;int&gt;</b></big></big>(<b>std::logic_error("Error")</b>);
    // error condition<br>
    &nbsp; if (x == 0) return std::make_ready_future(0); // immediate result<br>
    &nbsp; std::future&lt;int&gt; f1 = std::async([]() { return x+1; }); //
    asynchronous result<br>
    &nbsp; return std::move(f1);<br>
    }<br>
    <br>
    Would this addition acceptable?<br>
    <br>
    BTW, what was the rationale to provide only this single overload to
    std::promise<br>
    &nbsp; void promise&lt;R&gt;::set_exception(exception_ptr p);<br>
    <br>
    Why not adding<br>
    &nbsp; template &lt;typename E&gt;<br>
    &nbsp; void promise&lt;R&gt;::set_exception(E p);<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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 />
&nbsp;<br />
&nbsp;<br />

--------------000505080509050903040901--

.


Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Sat, 25 May 2013 15:37:44 +0300
Raw View
--047d7b3a831ca8222d04dd8a2ebd
Content-Type: text/plain; charset=ISO-8859-1

On 25 May 2013 14:49, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr>wrote:

>
> BTW, what was the rationale to provide only this single overload to
> std::promise
>   void promise<R>::set_exception(exception_ptr p);
>
> Why not adding
>   template <typename E>
>   void promise<R>::set_exception(E p);
>
>
>
It will have to be wrapped into an exception_ptr anyway, so it's alright to
have that type
in the function signature directly, I suppose.

--

---
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.



--047d7b3a831ca8222d04dd8a2ebd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 May 2013 14:49, Vicente J. Botet Escriba <span dir=3D"ltr">&l=
t;<a href=3D"mailto:vicente.botet@wanadoo.fr" target=3D"_blank">vicente.bot=
et@wanadoo.fr</a>&gt;</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"><br>
    BTW, what was the rationale to provide only this single overload to
    std::promise<br>
    =A0 void promise&lt;R&gt;::set_exception(exception_ptr p);<br>
    <br>
    Why not adding<br>
    =A0 template &lt;typename E&gt;<br>
    =A0 void promise&lt;R&gt;::set_exception(E p);<br>
    <br><br></div></blockquote><div><br></div><div>It will have to be wrapp=
ed into an exception_ptr anyway, so it&#39;s alright to have that type<br>i=
n the function signature directly, I suppose. <br></div></div><br></div>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

--047d7b3a831ca8222d04dd8a2ebd--

.


Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Sat, 25 May 2013 15:01:17 +0200
Raw View
This is a multi-part message in MIME format.
--------------090601010202060804020809
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 25/05/13 14:37, Ville Voutilainen a =E9crit :
>
>
>
> On 25 May 2013 14:49, Vicente J. Botet Escriba=20
> <vicente.botet@wanadoo.fr <mailto:vicente.botet@wanadoo.fr>> wrote:
>
>
>     BTW, what was the rationale to provide only this single overload
>     to std::promise
>       void promise<R>::set_exception(exception_ptr p);
>
>     Why not adding
>       template <typename E>
>       void promise<R>::set_exception(E p);
>
>
>
> It will have to be wrapped into an exception_ptr anyway, so it's=20
> alright to have that type
> in the function signature directly, I suppose.
>
>
Right. But the user needs to do it explicitly. Compare

   p.set_exception(std::make_exception_ptr(E()));

to

   p.set_exception(E());

The last one is shorter, enough explicit and clear.

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.



--------------090601010202060804020809
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:37, Ville Voutilainen a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
cite="mid:CAFk2RUb0xbxGdKZr8vHMquYu8f6m+4_GuaKdBS9a7H9M0_gnVg@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On 25 May 2013 14:49, Vicente J.
            Botet Escriba <span dir="ltr">&lt;<a moz-do-not-send="true"
                href="mailto:vicente.botet@wanadoo.fr" target="_blank">vicente.botet@wanadoo.fr</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div bgcolor="#FFFFFF" text="#000000"><br>
                BTW, what was the rationale to provide only this single
                overload to std::promise<br>
                &nbsp; void promise&lt;R&gt;::set_exception(exception_ptr p);<br>
                <br>
                Why not adding<br>
                &nbsp; template &lt;typename E&gt;<br>
                &nbsp; void promise&lt;R&gt;::set_exception(E p);<br>
                <br>
                <br>
              </div>
            </blockquote>
            <div><br>
            </div>
            <div>It will have to be wrapped into an exception_ptr
              anyway, so it's alright to have that type<br>
              in the function signature directly, I suppose. <br>
            </div>
          </div>
          <br>
        </div>
      </div>
      &nbsp;
      <br>
    </blockquote>
    Right. But the user needs to do it explicitly. Compare<br>
    <br>
    &nbsp; p.set_exception(std::make_exception_ptr(E()));<br>
    <br>
    to <br>
    <br>
    &nbsp; p.set_exception(E());<br>
    <br>
    The last one is shorter, enough explicit and clear.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an 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 />
&nbsp;<br />
&nbsp;<br />

--------------090601010202060804020809--

.