Boost logo

Boost :

Subject: Re: [boost] [coroutine] Experimenting with interfaces
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2012-09-21 14:09:41


On Fri, Sep 21, 2012 at 6:34 PM, Oliver Kowalke <oliver.kowalke_at_[hidden]>wrote:

> Am 21.09.2012 19:17, schrieb Eugene Yakubovich:
>
> [snipped example with coroutine-fn having void result]
>
> I'm not sure what this means for the best interface but I did want to
>> share these thoughts and examples.
>>
> thank you for your examples:
> If coroutine's template signature returns a type different from void it is
> required that the coroutine function does return the same type instead of
> void as in your example.
>
>
> template <typename C>
> void timer(C c, chrono::seconds interval) {
> // while( interval != chrono::seconds::zero() ) {
> // this_thread::sleep_for(**interval);
> // interval = c(interval);
> // }
>
> }
>
> coroutine<chrono::seconds(**chrono::seconds)> c(
> [](coroutine<chrono::seconds(**chrono::seconds)> c, chrono::seconds
> i) {
> timer(c, i);
> }
> );
>
> chrono::seconds s = c(chrono::seconds(1)); // [1]
>
>
> Which value has variable 's' after return from 'c(chrono::seconds(1))' ?
>

for seconds(1), it would simply return seconds(1), right? If you mean on
chrono::seconds::zero(), then the coroutine would return without yielding
any result. In this case, an option that would allow mantaining the
function-like interface would be to throw an exception from [1], or, if
operator() was called with std::nothrow as an additional first parameter,
return an optional. This was what the original library did on exceptional
returns and would work well here as well I guess. Note that 'coroutine'
could detect the result type of the coroutine-fn and decide what to do on
return depending on it, this way the user can decide the most natural
behaviour depending on the nature of the problem.

If you do not like the nothrow interface, maybe have a differently named
member (opt_call?) which returns an optional.

-- gpd


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