[cpp-threads] Re: Thread API interface tweaks

[Herb Sutter]

Howard, what Nick says reminds me of other reasons for future<void>. One is when you don't know or care about the value's type but you do want to take a future:

  future<void> f = SomeFnThatReturnsAFuture();

where I don't necessarily know the type of the future but I also don't really care (maybe I don't use it, or maybe I pass it on to other code). So future<T> should be implicitly convertible to future<void> if I'm not interested in the specific result -- again I agree this is more compelling in designs where future has other ops such as wait, is_ready, cancel, etc.

Then there's future_group, where sometimes you want the type:

  future<int> f1, f2;
  ...
  future_group<int> g1 = f1 || f2;
  int i = g1();

  // though note I kind of like this shorthand
  // and hope you'll want to support it:
  //   int i = ( f1 || f2 )();

Above I want to take whichever is ready first, but they're both ints so I want to preserve the typing.

But in the general case the types may not be compatible:

  future<double> f3;
  future_group<void> g2 = f1 || f3;
  g2.wait();

or there may not be a single value if there are &&'s in there:

  future_group<void> g3 = ( f1 || f2 ) && f3;
  g3.wait();

Just jotting down some thoughts quickly.

Herb



> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk
> [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf
> Of Nick Maclaren
> Sent: Tuesday, August 29, 2006 5:43 AM
> To: C++ threads standardisation
> Cc: David Miller; Alisdair Meredith; Terrence.Miller at Sun.COM;
> David Miller; Mattson, Timothy G; Bill Seymour; P.J. Plauger
> (Dinkumware Ltd); Bjarne Stroustrup; Bronis R. de Supinski;
> Pete Becker; Eric Niebler; Lawrence Crowl
> Subject: Re: [cpp-threads] Re: Thread API interface tweaks
>
> I am surprised that there are so many CCs, because I don't
> like them on mailing lists.  If most people do, I can try to
> remember to add them, but will indubitably forget.
>
> Kevlin Henney <kevlin at curbralan.com> wrote:
> >
> > This was not the particular usage I had in mind. Agreed, it
> does not
> > appear to be massively useful, although it is plausible. However,
> > banning things that are not massively useful but are
> plausible doesn't
> > appear to be a necessity, and even seems a little harsh in
> this case.
> > What I had in mind was the fact that multiple threads could
> wait for
> > the completion of a thread based on a future<void>.
> Although it is an
> > edge case, I reckon it would be more surprising to disallow
> > future<void> than to allow it, and I reckon following the
> principle of
> > least surprise would just tips the balance here.
>
> Well, I can think of a fair number of uses for void futures,
> so it would be more than just surprising if they are banned.
> For example:
>
> A database or I/O system could spin off output, close or
> similar operations with no interest in the result, except for
> success or failure.  That could be 'returned' either in a
> global variable or by an exception.  Also, the wait function
> could be a 'wait for all futures on this list and stop the program'.
>
> Now, you can reasonably say that this a poor programming
> style (I don't agree, but it is a matter of taste), but it
> assuredly is a common paradigm.
>
>
>
> Regards,
> Nick Maclaren,
> University of Cambridge Computing Service, New Museums Site,
> Pembroke Street, Cambridge CB2 3QH, England.
> Email:  nmm1 at cam.ac.uk
> Tel.:  +44 1223 334761    Fax:  +44 1223 334679
>
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>