Re: [boost] Futures Review Starts Today - January 5, 2009

Subject: Re: [boost] Futures Review Starts Today - January 5, 2009
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2009-01-06 02:02:54

I'm refering to the updated version of Anthonys library at http://www.justsoftwaresolutions.co.uk/files/futures_documentation.html because http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp seams not to be up-to-date (missing some functionality like lazy futures)!

> What is your evaluation of the design(s)?
> What is your evaluation of the implementation(s)?

Both libraries are good designed and provide:
- value transfer
- exception transfer (Braddock uses its own exception_ptr implementation)
- lazy futures (result is not actually computed until it is requested via future::get() )
- a wrapper class for wrapping callable objects (future_wrapper, packaged_task)

Task chaining  - Braddocks implementation provides a callback mechanism if the future becomes ready (result was set). This allows chaining of tasks (used in boost.threadpool). This functionality seams not to be provided by the lib from Anthony.

Wait callbacks are provided only by Anthonys implementation.

Move semantics are only provided by Anthonys lib.

> What is your evaluation of the documentation?

Content of both documentations is sufficient - Braddock doesn't conform to the boost documentation style (Quickbook/Boostbook).

> What is your evaluation of the potential usefulness of the library(s)?

Both libaries are useful and share same functionality but also provide additional functionality (ready callback, wait callback, move semantics).

> Did you try to use the library? With what compiler(s)? Did you have
> any problems?

I used Braddocks library and the N2561-future (old one) library. 

Linux, FreeBSD 7.0 -> gcc-4.3
OpenSolaris -> gcc-4.2
Windows XP Prof -> vc-9.0

> How much effort did you put into your evaluation(s)? A glance? A quick
> reading? In-depth study?

maybe you can say in-depth

> Do you think the libraries should be accepted into Boost as-is or
> should they be merged?
 
> The ideal outcome in my mind would be a resubmitted submission,
> incorporating the best ideas from each.  Tell me if you share this view 
> or what is your preferred result.

The library provided by Anthony seams to be more feature complete and the interface should be more conform to the future C++0x standard.
Thatswhy I would vote for Anthonys lib if completion callbacks (future result was set -> task chaining) are provided.

regards,
Oliver
-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger