13 Sep
2012
13 Sep
'12
6:51 p.m.
Le 13/09/12 19:36, Oliver Kowalke a écrit :
> 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)
>
>
The storage type of R& should be R*. This is how boost futures manage it.
Best,
Vicente