Boost logo

Boost :

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


> Especially if generator does not support movable-only types, I am
> afraid that this will be a common tripping point. Giovanni's design
> had the same issue which he advised to avoid by using the iterator
> like interface (using operator* and operator++).

It is an issue of boost.tuple - if tuples can handle moveable objects, boost.coroutine will handle it too.

> 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?
 
> I'm not really sure about what to do about is_complete() or operator
> unspecified-bool-type(), though. Maybe they are not needed at all?

coroutines are used like this:
 - 'if ( coro)' // coroutine has an coroutine-fn attached and can be used
 - 'coro.is_complete()' coroutine has returned and can not resumed

generators:
 - 'if (gen) // generator is valid and has an value so that 'gen()' returns a value

generators have no 'is_complete()' function (contained in the unspec_bool operator()).

> I admit that this interface might be a bit quirky but if the library
> also provides input iterator, that can become the primary interface.
> Generators are used to produce sequences and iterators are the central
> mechanism of dealing with sequences in C++. So the iterator usage
> could be:
>
> for( gen_t::iterator it = g.begin(); it != g.end(); ++it ) {
> X* val = *it; // no dangling pointers
> }
>
> (or BOOST_FOREACH, C++11 range-based for, or for_each).
>
> g.begin() or gen_t::iterator ctor would invoke the generator-function
> for the first time and ++it for all subsequent times.

Shouldn't iterators be implemented on top of generators/coroutines?

Oliver


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk