Re: [boost] [coroutine] interface suggestion

Subject: Re: [boost] [coroutine] interface suggestion
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2012-09-20 09:41:16

On Thu, Sep 20, 2012 at 12:17 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 20/09/12 12:18, Giovanni Piero Deretta a écrit :
>
>  On Thu, Sep 20, 2012 at 3:51 AM, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]> wrote:
>>
>>> Note that as I commented in some of my first post related to bind, you
>>> must take care of const and reference  parameters in some tricky ways, as
>>> in order to be able to reassign them you should do some casts. I hope
>>> this
>>> will not cache some undefined behavior.
>>>
>>>  How would you exactly rebind references? I can't see any sane way to do
>> it.  I would expect the following code to work:
>>
>> int i = 0, j = 0;
>> coroutine<void(int&)> coro([&](caller_t& caller, int& x) {
>>                 caller.bind(x);
>>                 assert(&x == &i); // ok
>>                 caller.yield();
>>                 assert(&x == &y); // ?????
>> });
>>
>> coro(i);
>> coro(j);
>>
>
> Yes, references could not be rebound. We could rebind types, pointers but
> not references.
> I guess the coroutine library could store a pointer on the caller object,
> and allow to obtain them using get<>. But in this case the coroutine
> function could not follow the coroutine signature.

you mean that caller_t::yield does not really model "int&()"? Well, this is
an issue. As far I understand, currently Oliver is leaning on passing the
parameters to the coroutine-fn, having yield() return a tuple, and having
the coroutine-fn return the final result. This means that yield() will
closely follow the signature and everything is fine.

If instead he decides to go with the get<> interface, then maybe it is time
to abandon the coroutine as a function model.

-- gpd