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