Add C++11 range utilities #2734
Conversation
| { | ||
| Range values_ = traits::acquire_future<Range>()(values); | ||
| return lcos::when_all(std::move(values_)); | ||
| } |
There was a problem hiding this comment.
What's the rationale to drop this overload?
There was a problem hiding this comment.
This overload becomes redundant, given the changes to the overload above.
| typedef typename frame_type::init_no_addref init_no_addref; | ||
|
|
||
| boost::intrusive_ptr<frame_type> p(new frame_type( | ||
| util::forward_as_tuple(std::move(values)), init_no_addref()), | ||
| util::forward_as_tuple(std::move(lazy_values_)), init_no_addref()), |
There was a problem hiding this comment.
Shouldn't we rather std::forward the lazy values?
There was a problem hiding this comment.
No. That might have made some sense (not really) back when std::vector was the only thing accepted as a range, but now the function will accept non-owning ranges as well, and needs to acquire the shared states explicitly so as to guarantee they stay alive long enough.
There was a problem hiding this comment.
Then I am a little confused. The function takes a forwarding reference, yet you move it unconditionally. How does it work? Wouldn't when_all_frame capture it correctly even if it was forwarded?
There was a problem hiding this comment.
We don't move from the argument lazy_values, but from a local lazy_values_ initialized by acquiring all the futures in the range given as argument. This is rather subtle, but a common pattern within the whens.
That said, it looks like the implementation of acquire_future might be insufficient to properly support non-owning ranges. I'll have to look into that.
There was a problem hiding this comment.
Ahh, thanks for the clarification. I missed the underscore...
No, no measurement was performed. Compile time improvements is not the rationale of this PR, though it'd be a colorful datapoint to have if someone's interesting in doing the work. |
|
Yes, I can see that a reduction of compile times wasn't the point here. A difference in compile times would be interesting nonetheless. |
… implementation, patch broken whens
No description provided.