Re: [c++0x] <future>

[Benjamin Kosnik <bkoz at redhat dot com>]

> Here is an implementation of <future>

Nice!
 
> This is as near as possible to the current working paper, n2857:
> concepts, constexpr, new allocator support and explicit conversion
> operators are missing.
> There are some preprocessor conditions around missing features and g++
> bugs, I'll remove them from the final version, this is really just to
> let people try it out or comment, as I might be unable to work on it
> again until next week.

Thanks for the heads up. It looks like c++/40007 is being worked on, so
I'm hoping those ifdef 0 parts goes away when this patch is checked in.
Is that your plan as well? 

Also, for the concept bits, I would rather see them commented vs. if
defed. I think that is what the rest of the library is doing. You know,
more like comment guidelines... 

;)

> The implementation is a pretty simple one using a mutex and condition
> variable (smarter versions using atomics to eliminate some locking are
> possible.) Most of the code that doesn't depend on the type of
> future/promise is in _Future_state_base for the shared state, or in
> _Future_impl for the per-instance state.  That was done to reduce the
> amount of code instantiated for every template specialisation.

Sounds reasonable.

> As I've implemented it, you'll get a segfault if you use almost any
> member function on a future/promise after a std::move.  That's
> intentional: the only requirement is that they can be safely
> destroyed, so I didn't add any checks for empty shared_ptr.  

Hmmm. This doesn't seem like a friend-making move. At least add a
comment or note about this.

> I'm
> thinking of adding some checking for debug mode (IMHO we should be
> adding debug mode support to all new components where possible.)

Agree with this. Certainly there would be a value to debug versions of
 concurrency components.
 
> The tests in this patch are a bit of a hodge-podge, some use
> test01/test02 functions called by main, some have the test code
> directly in main()... please let me know if I need to rework them.

Please try to keep all test cases with minimal main functions, which
call a test function or functor and return 0.

> I've also got some python pretty printers ready for futures and
> promises, which I'll be able to add once Tom T. and Phil M. commit the
> python stuff from project Archer (hint hint! ;-) so gdb will give you
> useful info about the state such as "promise<int> (exception ready, 3
> associated futures)" or "promise<Foo&> (not ready, no associated
> futures)"

yay!

best,
benjamin