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

Subject: Re: [boost] [Review.Coroutine] Vicente's review
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2012-09-13 13:36:55

Am 13.09.2012 18:43, schrieb Vicente J. Botet Escriba:
> Le 13/09/12 17:38, Oliver Kowalke a écrit :
>> Am 13.09.2012 16:42, schrieb Vicente Botet:
>>>
>>>>
>>>> generator< int > gen( f);
>>>> if ( optional< int > val = gen() ) {...}
>>>>
>>>> if the generator function simple returns (no yield() called) then 
>>>> gen()
>>>> returns a none (== invalid/unset optional).
>>>>
>>> I don't think optional should be used. The user must know if it can 
>>> call the
>>> generator to get the next value or not.
>> That was my previous design. The user has to check the generator like:
>>
>> if ( gen) before asking the next value
>>
>> if ( gen) {
>>    int x = gen();
>>    ...
>> }
>>
>> 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()).
>>
> Why did you stored the pre fetched value in an optional<>l in the old 
> design? Storing it in R seems enough to me, and with move semantics, 
> moving it.
- return type of 'R &' would require that the member has to be 
initialized in the ctor (before pre-fetch() )
- optional<> allows to express 'non set' / 'invalid' easily (for 
instance in case of an exception)