Boost logo

Boost :

From: Oliver.Kowalke_at_[hidden]
Date: 2007-03-16 03:23:38

Hello Braddock,

> There is a new version of my future implementation at:
> -fixed this seg-fault problem that Oliver found
> -added a bunch of new unit tests, including some multi-thread
> ones which exercise various timing permutations.
> -added support for automatic conversions of types which are
> assignable, as discussed with
> promise<int> p;
> future<long> lf(p);
> future<unsigned char> ucf(p);
> I learned a lot from Frank's libpoet implementation for this
> typing magic, but tried to do things a bit tighter. There is
> no future "proxying" or "chaining"
> of futures, per se, instead all future references point to
> the same implementation object under the hood, but do
> abstract the actual retrieval of the value. The effect is
> largely the same. The promise/future split helps a lot.
> I haven't done the same assignment type conversions to the
> promise class yet, but I suppose I should.
> Braddock Gaskill
> Dockside Vision Inc


I still believe that futures should be combinable via operator&& and
operator|| - for users of the boost::future library is it more intuitive
that the resulting future of an future comination contains the result
instead of future<bool> and be force to check all related futures for
their return status and return value.
I would prefer following syntax:

promise< T1 > p1;
future< T1 > f1( p1);
promise< T2 > p2;
future< T2 > f2( p2);
promise< T3 > p3;
future< T3 > f3( p3);

future< tuple< T1, T2, T3 > f( f1 && f2 && f3);
future< variant< T1, T2, T3 > f( f1 || f2 || f3);
future< tuple< T1, T2, T3 > f( f1 && f2 && f3);
future< variant< tuple< T1, T2>, T3 > f( f1 && f2 || f3);

as Hartmut suggested.

regards, Oliver

Boost list run by bdawes at, gregod at, cpdaniel at, john at