I apologize for delayed response. On Fri, Oct 5, 2012 at 10:22 AM, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
Version 1) requires that coroutine-fn has only one argument == coroutine<>::self_t. Other arguments are accessed via coroutine<>::self_t::get< int >() and results via coroutine<>::get(). interface provides input/output iterators.
typedef coroutine< int( int, int> > coro_t; int fn( coro_t::self_t & c) { int x = c.get< 0 >(); int y = c.get< 1 >(); c.yield( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get();
I only like yield if there's a separate generator class. For general coroutines, I would prefer the second version. But I'm torn if it makes sense to have a separate generator class. It's just sugar but it might lower the learning curve.
Version 2) requires that coroutine-fn has only one argument too == coroutine<> with inverted signature. Other arguments are access via coroutine<>::get(). interface provides input/output iterators.
typedef coroutine< int( int, int> > coro_t; int fn( coroutine< tuple< int, int >( int) & c) { int x = c.get().get< 0 >(); int y = c.get().get< 1 >(); c( x +y); ... } coro_t coro( fn); int res = c( 3, 7).get();
Overall, I do like this interface. Like I mentioned before, I would like to see the coroutine-function with a void return type. Or have an option for that. Maybe the coroutine can support both by looking at the return type of the passed in function and adjusting accordingly. The only problem with that is it would make it harder to have a type deducing function, i.e. make_coroutine. As for output iterators, I see that it's currently only supported for coroutines with void return type and arity of 1. If a coroutine has a non-void return type, output iterator can still be defined, just ignore the return values. Maybe also support arbitrary arity by having the iterator's value_type be a tuple for arities larger than 1. Regards, -Eugene