Re: [boost] Boost.Fiber review January 6-15

Subject: Re: [boost] Boost.Fiber review January 6-15
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2014-01-09 10:06:16

On 09/01/2014 05:06 a.m., Oliver Kowalke wrote:
> 2014/1/9 Agustín K-ballo Bergé <kaballo86_at_[hidden]>
>
>> - The constructor takes a nullary function, instead of a callable and an
>> arbitrary number of parameters.
>
>
> will collide with the additional parameters required by fibers and not part
> of boost::thread/std::thread
> for arbitrary number of parameters bind() could be used
>
>> The order of parameters of the overload taking attributes does not match
>> that of boost::thread.
>>
>
> the attributes control things like stack-size which is not required by
> boost::thread
>

boost::thread has a constructor taking attributes too, this is the first 
argument so there would  be no collision. This should be adjusted not 
only to be coherent with boost::thread, but also to implement the 
general constructor since matching the same semantics otherwise is 
tricky. Consider:

     boost::fiber fib{
       [f = std::move(f), a0 = std::move(a0), ...]() mutable
       {
           std::move(f)(std::move(a0), ...);
       };
     }

against the standard conformant constructor with the same semantics:

     boost::fiber fib{std::move(f), std::move(a0), ...};

>> - There is no notion of explicit operator bool in neither boost::thread
>> nor std::thread.
>>
>
> add for convenience to the if a fiber instance is valid or not (== check
> for not-a-fiber)
>

I understand the perceived convenience of semantic sugar, to me it is an 
unnecessary divergence from std/boost::thread. However, I can always 
avoid their use completely.

>> - There is an operator < for fibers and none for id. There should be no
>> relational operators for fiber, and the full set for fiber::id as well as
>> hash support and ostream insertion.
>>
>
> id has 'operator<' etc.
>

Please add reference documentation for fiber::id.

>> - There is no indication whether the futures support void (I assume they
>> do) and R& (I assume they don't).
>
>
> future supports future< R >, future< R & >, future< void > - the problem
> was how to express it in a comfortable way in the docu
>
>> - The documentation for promise doesn't seem to support void, it is
>> unclear whether they support references. Another explicit operator bool.
>>
>
> promise supports promise< R >, promise< R& >, promise< void > - suggestions
> how to write the docu without repreating the interface for the
> specializations?
>

Refer to the standard for a concise definition of future/promise. It 
basically defines the specializations only when they differ.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com