Re: [boost] [SoC][Coroutine] Coroutine design

From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 2006-05-06 13:52:51

Xi Wang wrote:
> On 5/6/06, Giovanni P. Deretta <gpderetta_at_[hidden]> wrote:
>> [ some explaination here ]
> Got it. Thanks a lot for the detailed explanation :-)
> So the return value (tuple) of a call to a yield in the coroutine body is
> the parameters of the subsequent invocation to the coroutine object, right?

Exactly.

> [...] 
> The "return" I mentioned was just to guide the compiler to check the return
> type
> rather than to exit the function (of course it should not). More clearly,
> suppose real_yield is a global yield function, not type-safe.
> #define yield(x) \
>     if (FALSE) return x; \
>     real_yield(x);
> This macro would help to check the return type, and "return x" is never
> called.
> However, in this case, the return value (tuple) of real_yield could not be
> retrieved.
> So just forget it:-)

Also this wouldn't work if yield is invoked from a subroutine called 
from a coroutine. Still the trick is interesting. I didn't understand it 
the first time you proposed it.

Btw, IF the coroutine body is actually a function object AND there is 
only one operator() for that object AND yield is only called from 
operator() (and not from any other subroutine), may be something like 
this could work (i did not try it):

#define yield(x) \
        real_yield(&this->operator(), x)

(real_yeld is a global template function that will chose its arguments 
and return type according to the signature of the first function 
parameter that is passed to it)

If operator() is overloaded the compiler will complain that address_of 
call is ambiguous. If yield is called from a free function it will 
complain that 'this' cannot be found. If yield is called from a functor 
called from the coroutine body, things can go very very badly.

This macro can break in so many ways that it is not fun...

Thanks again for the feedback.

-- 
Giovanni P. Deretta