Re: [Boost-users] [coroutine] new versions

Subject: Re: [Boost-users] [coroutine] new versions
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-10-12 03:31:47

On Fri, Oct 5, 2012 at 8:22 AM, Oliver Kowalke <oliver.kowalke_at_[hidden]>wrote:

> I've uploaded two re-factored versions - I think most of the suggestions
> from the review are implemented (namespace is not corrected and
> documentation not updated yet).
>
> 1.) http://ok73.ok.funpic.de/**boost-coroutine-self.zip
>

> 2.) http://ok73.ok.funpic.de/**boost-coroutine-coro.zip
>
>
> Version 1) requires that coroutine-fn has only one argument ==
> coroutine<>::self_t. Other arguments are accessed via
> coroutine<>::self_t::get< int >() and results via coroutine<>::get().
> interface provides input/output iterators.
>
> typedef coroutine< int( int, int> > coro_t;
> int fn( coro_t::self_t & c) {
>     int x = c.get< 0 >();
>     int y = c.get< 1 >();
>     c.yield( x +y);
>     ...
> }
> coro_t coro( fn);
> int res = c( 3, 7).get();
>
>
> Version 2) requires that coroutine-fn has only one argument too ==
> coroutine<> with inverted signature. Other arguments are access via
> coroutine<>::get().
> interface provides input/output iterators.
>
> typedef coroutine< int( int, int> > coro_t;
> int fn( coroutine< tuple< int, int >( int) & c) {
>     int x = c.get().get< 0 >();
>     int y = c.get().get< 1 >();
>     c( x +y);
>     ...
> }
> coro_t coro( fn);
> int res = c( 3, 7).get();
>
> Both implementations are not optimized - I think we should get a small and
> clean interface first.
> Comments?
>

FWIW, I (presently) prefer the syntax and symmetry in 2). Maybe for
ease-of-use you can also submit a macro to Boost.Fusion that "unpacks and
initializes" the arguments into local variables, something that allows you
to do

BOOST_FUSION_UNPACK( ( int x ) ( int y ), c.get() ) // Or maybe it could
work with just "c"? Or maybe "c.result()" would be better?

I have such a macro implemented, so could help with such a feature. It's
basically an extension of tie'ing.

It looks like there's still a question on when the coroutine function body
is entered: upon construction of the coroutine object or upon the first
call? Seems like the natural thing would be upon the first call, separate
from the coroutine construction, but...yeah I admit I don't fully grasp the
pros and cons of each convention. And this seems sufficiently important to
get right. Sorry, that's probably not very helpful :)

- Jeff