Le 20/09/12 08:19, Oliver Kowalke a écrit :
Note also that the access to the parameters need to be done using the get function on functions called by the coroutine function such as the below function 'g'.
int f( caller_t & c, strg & s, int x) { caller_t::yield_t b = c.bind( s, x); // s and x are now used to store the next calls.
b.yield( s.length() + x ); // here s and x have been reassigned g(b);
}
void g( caller_t::yield_t & b) { b.yield( b.get<0>.length() + 2*b.get<1> ); // here s and x have been reassigned }
As you can see, the function called *could* not have the s and x parameters and could not return int, that is, needs just the yield context. OK - it should not be to hard to implement this. See more on the replay to Giovanni. I agree that generator<> could get an iterator interface (output-iterator fro caller generator, input-iterator in generator<>-fn) But I'm not convinced that the coroutine<> template should have an iterator interface. How does the syntax look like for coroutine-fn with multiple parameters (for instance f() in the example above)?
I don't think a generic coroutine should have an iterator interface. But coroutine <T<()> and coroutine <void(T)> could as Giovanni posted already. Best, Vicente