Re: [boost] [Review.Coroutine] Vicente's review

Subject: Re: [boost] [Review.Coroutine] Vicente's review
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-09-13 12:49:09

Le 13/09/12 18:39, Eugene Yakubovich a écrit :
>> This design required pre-fetching and storing the return value via a context
>> jump into the generator routine.
>> Only with this mechanism I was able to know if the next call to
>> generator<>::operator() will return a value.
>> (requires that the first pre-fetch is done in the ctor of generator<>
>>
>> The difference to the actual design
>>
>>
>> if ( optional< int > val = gen() ) {
>>     ....
>> }
>>
>> is that I don't need to pre-fetch and not to store the optional<> as
>> parameter (optional is only created inside generator<>::operator()).
>>
> If the generator-function returns non-void (original design) and has
> no yield_break, then it's possible for generator::operator() to return
> R (not optional<R>) and do no prefetching. But personally, I would
> rather take the optional<R> with a void generator-function and provide
> the iterator (iterator::operator* will return R, not optional<R>) as
> the preferred interface.
+1.
>
>
>>>>> * The access to the actual coroutine parameters is asymmetric, letting
>>>>> access to old actual parameters that can point to objects that have
>>>>> already
>>>>> been destroyed.
>>>>>
>>>>> Maybe the self_t object could take care of this (or this_coroutine).  We
>>>>> can use a get<> function to give access to the actual parameters.
>>>>>
>>>>>        int f20(coro_t::self_t  &  self)
>>>>>        {
>>>>>            self.yield(2*self.get<0>());
>>>>>        }
>>>>>
>>>>>
>>>>>        int f20()
>>>>>        {
>>>>>          typedef this_coroutine&lt;int(int)&gt; this_coro;
>>>>>            this_coro::yield(2*this_coro::get<0>());
>>>>>        }
>>>> interesting idea, I find it better than the version using bind because
>>>> you
>>>> don't can't forget to 'bind'. you are always required to use
>>>> self_t::get<>().
> One could still do this:
>
> int f20(coro_t::self_t  &  self) {
>      X& x1 = self.get<0>();
>      self.yield();
>      X& x2 = self.get<0>();
>      // use x1 and x2 here. x1 might be bogus now
> }
You are right. This is why I prefer the bind approach, if doable.
> Maybe the example is a bit contrived but not anymore than the original
> one where the use of formal parameters posed the same danger. Even
> with bind(), one could create a ref/ptr to the bound variable that
> would be bogus after the next yield().
I don't see the problem with bind. Could you show an example?

Best,
Vicente