[...]
This non-allocating implementation is an interesting argument in favor of
On 26 May 2015 12:59 am, "Peter Dimov" wrote:
the current "unique future", which I've long disliked. I prefer futures to
be shared_futures.
Interesting, why do you dislike the unique future design? A shared future
pretty much requires holding a shared pointer and needs heavy weight
synchronisation ( a muted+condvar or equivalent). On the other hand a
unique future need no internal mutual exclusion and the only
synchronisation is needed for the handoff between producer and consumer;
the reference count is implicit (just have the consumer always deallocate
the object). The implementation can be significantly more light weight.
-- gpd
_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost