Hello Braddock,
There is a new version of my future implementation at: http://braddock.com/~braddock/future/
CHANGES: -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 Frank...ie: 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
Thanks! 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