Re: [boost] {Review] Coroutine reviewstarts today, September 3rd

Subject: Re: [boost] {Review] Coroutine reviewstarts today, September 3rd
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2012-09-11 11:51:28

Am 11.09.2012 17:43, schrieb Eugene Yakubovich:
>>> Maybe we can change behavior so that generator's constructor does not
>>> invoke the generator-function, only operator() does. And change
>>> operator() to return optional<R> instead of R. The usage can then be:
>>>
>>> gen_t g(foo);
>>> while( optional<X> val = g() ) {
>>>      // use val.get()
>>> }
>> what would be the benefit?
>>
> This would eliminate the "early destruction" problem described before.
> The generator would end up not storing a value (which it currently
> does in detail::generator_resume::result_) and operator() would just
> return whatever the generator-function yielded or optional<none> if
> the generator-function exited.
OK - maybe I should implement it and test the timings of both versions

>
>> Shouldn't iterators be implemented on top of generators/coroutines?
>>
> Yes, that is definitely a good option. My thinking of putting the
> iterator "inside" the generator was to potentially avoid constructing
> optional<R> -- which would otherwise be needed if the generator's
> interface was like the one proposed above. Iterator could then use
> private methods of generator and not the public interface. I'm not
> sure if there's really any overhead to constructing optional<R> so it
> might not really matter.
>
> Also, looks like Boost.Optional does not yet support moveable-only
> types so having the iterators not use it can bring quicker support of
> movable-only types (after tuples support them). Granted, only the
> iterator interface would be usable with movable-only types.
>
> Oliver, if you would like, I can code up my proposed changes and send
> in the patch. It might make it easier to explore the design.
OK

regards,
Oliver