Re: [boost] Coroutines and Output Iterators

Subject: Re: [boost] Coroutines and Output Iterators
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-10-10 21:05:15

On Sat, Oct 11, 2008 at 12:35 AM, Hartmut Kaiser
<hartmut.kaiser_at_[hidden]> wrote:
>> > What I propose is thus to make an output iterator that will yield the
>> data
>> > within a coroutine context.
>> > With that solution, one writes generators as functions writing to
>> output
>> > iterators, but those iterators might as well be writing to containers
>> than
>> > actually yielding the result, which means the person designing the
>> generator
>> > does not have the overhead of coroutines forced upon him.
>> >
>> <SNIP>
>>
>> In fact I have been planning for a long time to make the 'self' type
>> be a functor. The interface to yield a value would change from the
>> current:
>>
>> template<Self>
>> my_result my_gen(Self& f) {
>>    for(....)
>>        self.yield(val);
>>    self.exit();
>> }
>>
>> to:
>>
>> template<F>
>> void my_gen(F f) {
>>     for(...)
>>         f(val);
>> }
>>
>> (note the switch from pass by reference to pass by value)
>> Making an output iterator from 'f' is trivial via
>> boost::function_output_iterator.
>
> This isn't such a good idea, IMHO. I'm using the GSoC version for quite some time now and this Self instance is a good place to store/access fiber specific data (similar to thread specific storage, but not has no thread affinity, i.e. is available regardless of which thread actually executes the fiber/coroutine).
>

Well, treating the self instance as a function object doesn't prevent
other more ad hoc uses. Generic code that doesn't care just treats it
as a function object, more specialized code that is coroutine aware
can have access to other functionality. The change I have in mind is
basically just changing self_type::yield to self_type::operator() (and
supporting copy semantics).

-- 
gpd