Opened 8 years ago
Closed 7 years ago
#10664 closed Bugs (wontfix)
Missing support with respect to moves
Reported by: | anonymous | Owned by: | olli |
---|---|---|---|
Milestone: | To Be Determined | Component: | coroutine |
Version: | Boost 1.56.0 | Severity: | Problem |
Keywords: | Cc: |
Description
Some parts of the documentation suggests that coroutines can be used with move-only types (e.g. boost::coroutines::asymmetric_coroutine<std::unique_ptr<int>>):
If R is a move-only type, you may only call get() once before the next asymmetric_coroutine<>::pull_type::operator() call.
However, if the template parameter is a move-only type, symmetric_coroutine<>::yield_type::get() may only be called once before the next symmetric_coroutine<>::yield_type::operator() call.
However those get members are implemented as some form of return * result_;, where the result type is that move-only type. This rightfully won't work.
Note that using the input iterator (in the asymmetric case) works, because its operator* uses the get_pointer() member (of the non-public implementation) rather than get().
My first thought on how to solve this is to elaborate the public interface, as I believe only one get() member won't cut it. Even if e.g. get() performs some equivalent of return move(*result_); for move-only types, there is a missed opportunity for copyable types that have an optimized move. Consider a coroutine of std::vector<int>, for which we only call get() at most once per value yielded: we would like each value to be passed around with moves, to avoid unnecessary allocations.
IOW, there is a clear separation of concerns between a getter that can be called at most once, for which returning by value is a natural fit; and a getter that can be called any number of times, for which returning by value is not unheard of, but in which case it shouldn't compile for move-only types--although the presence and uses of get_pointer() suggests a need for returning by reference. This makes it possible at all to write correct generic code, too:
auto f(Functor functor, Coro& coro) { // for a double-duty get(), we can't tell if // we're performing two moves (which is bad) // or two copies (which could be inefficient) return functor(coro.get(), coro.get()); // okay: this won't compile for move-only types, and // this performs the required work when we really need // additional copies return functor(coro.get_copy(), coro.get_copy()); // a savvy programmer that wants as few copies as possible, // when moves are assumed to be acceptable, has the tools // to achieve that goal: auto copy = coro.get_copy(); return functor(move(copy), move(coro.get_reference())); // minimal work: one copy, one move // possible thanks to the sequencing guarantees of { } return Foo { coro.get_copy(), move(coro.get_reference) }; // okay, doesn't even require moveability return functor(coro.get_reference(), coro_get_reference()); // not okay, can't be caught by the compiler but hopefully // obvious to the programmer return functor(coro.get_move(), coro.get_move()); }
(The names are painfully spelled out for the purpose of illustration and not a serious suggestion.)
moveable types are supported by boost.coroutine2