On Fri, Oct 5, 2012 at 8:22 AM, Oliver Kowalke <oliver.kowalke@gmx.de> wrote:
I've uploaded two re-factored versions - I think most of the suggestions from the review are implemented (namespace is not corrected and documentation not updated yet).

1.) http://ok73.ok.funpic.de/boost-coroutine-self.zip
2.) http://ok73.ok.funpic.de/boost-coroutine-coro.zip

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();


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();

Both implementations are not optimized - I think we should get a small and clean interface first.
Comments?

FWIW, I (presently) prefer the syntax and symmetry in 2). Maybe for ease-of-use you can also submit a macro to Boost.Fusion that "unpacks and initializes" the arguments into local variables, something that allows you to do

BOOST_FUSION_UNPACK( ( int x ) ( int y ), c.get() ) // Or maybe it could work with just "c"? Or maybe "c.result()" would be better?

I have such a macro implemented, so could help with such a feature. It's basically an extension of tie'ing.

It looks like there's still a question on when the coroutine function body is entered: upon construction of the coroutine object or upon the first call? Seems like the natural thing would be upon the first call, separate from the coroutine construction, but...yeah I admit I don't fully grasp the pros and cons of each convention. And this seems sufficiently important to get right. Sorry, that's probably not very helpful :)

- Jeff