On 13-10-17 20:59, Phil Endecott via Boost wrote:
Specifically, I've been wondering whether the imminent arrival of low-overhead coroutines ought to change best practice for this sort of interface.
That's nice, but it can't inform the design of a library that exists now. Of course, the interface would be best served if it didn't exclude better¹ options in the future. ¹ coroutines are not zero cost On 13-10-17 20:59, Phil Endecott via Boost wrote:
Now, with stackless coroutines due "real soon now", we can avoid needing explicit state on either side.
Coros have explicit state but with syntactic sugar. The syntactic sugar in this case has runtime overhead.
Questions: how efficient is this in practice?
In practice it should be profiled, but it _will_ have overhead.
Is this really simpler to write than a non-coroutine version?
In all but the most trivial cases I think it's simpler. To write.
Will all of our code use this style in the (near?) future?
How should we be writing code now so that it is compatible with this style in the future? This is the most relevant question. I applaud it being asked. I don't have the answer yet. Slightly related, in my book, may be the way in which Boost Asio caters for different async patterns (yield_context, use_future or direct handlers). Asio coded the logic into the async_result customization
Will all of our code use this style: Most definitely not (because then we'd not be using C++, the language that exists to eliminate overhead) point. (http://www.boost.org/doc/libs/1_65_1/doc/html/boost_asio/reference/async_res...) I suppose we could learn by assimilating a device like that. Seth