[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] Updated version of futures library
From:       Frank Mori Hess <fmhess () speakeasy ! net>
Date:       2008-05-31 23:20:55
Message-ID: 200805311920.56078.fmhess () speakeasy ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Saturday 31 May 2008 17:14, Hartmut Kaiser wrote:
> > On Saturday 31 May 2008 14:30, Hartmut Kaiser wrote:
> > > > I.e.  future<bool> operator&&(future<bool>& lhs, future<bool>&
> > > > rhs) would return a new future which is equal to true, iff
> > > > lhs.get()==true and rhs.get()==true. If either one returned false
> >
> > it
> >
> > > > would be false and otherwise the composed future would not be
> > > > ready yet.
> > >
> > > Doing it the way you're proposing implies shortcutting operator&&(),
> > > which can't be implemented.
> >
> > left-to right evaluation can't be short-circuited, but he's talking
>
> Right, that's exactly my point.
>
> > about short circuiting in time, as either the lhs or rhs futures
> > complete.
>
> Didn't we talk about operator&&()? No 'either/or' here, only both
> futures. Additionally, the same comments apply as outlined below.

I'm pretty sure he's not talking about your "wait_for_all" operator&&() at 
all, he's talking about one with semantics closer to the "real" operator&& 
defined by the language.

> My main point was that such operator overloads apply to the result types
> and not the futures themselves, which adds unnecessary semantics and
> defeats separation of concerns. And, BTW, this is very much like the
> default conversion operator to the result type for the futures which -
> as most have agreed - is a bad idea.

It only appears to defeat "separation of concerns" because you're not 
separating your definition of the future logical operator overloads from 
his.  They really are two different ideas and are not useful for the same 
things.  Personally, I don't particularly want to see a future library 
overload any logical operators at all, or at least have the overloads 
sequestered in separate headers that aren't included by any of the other 
future library headers.

[Attachment #5 (application/pgp-signature)]

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[prev in list] [next in list] [prev in thread] [next in thread]