13 Sep
2012
13 Sep
'12
5:36 p.m.
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)