Boost logo

Boost :

Subject: Re: [boost] [coroutine] interface suggestion
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-20 07:20:46

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at