On 28 Aug 2015 6:34 am, "Thomas Heller" <thom.heller@gmail.com> wrote:
On 08/27/2015 04:04 AM, Niall Douglas wrote: <snip> A lot of things about future vs. shared_future... </snip>
Thoughts?
Ok, after reading all the other messages in this and other threads I am
starting to understand what the real problem is (all this is IMHO, of course):
The biggest mistake in your design is that of the functions taking
"preconditions". This brought you all this mess. The problem is, those are actually not preconditions but actually arguments to the function, more specifically, your "precondition" is always (?) the handle (or a future to the handle so to speak) to the actual operation that is being performend for which you need to get the value. That all is a result of the non-existing single responsibility pattern in your code. After getting rid of that, you will see that most of the points you brought up against using std::future (or boost::future) will actually go away.
Here is my concrete suggestion: - Let your async functions return a future to their result! (Not a tuple to the handle and the result...) - Don't use futures as arguments to your async functions. Say what you want as input!
Let's take on your read example... and suppose we have the following two function signatures:
future<handle> open(std::string name); future<std::vector<char>> read(handle const & h, std::size_t bytes, std::size_t offset);
See how easy, clear and succinct those functions are? Almost self explaining without any further documentation.
Couldn't possibly agree more. I was going to focus on this issue on my review. Thanks for explaining it so well. -- gpd