Boost logo

Boost :

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.


Agustín K-ballo Bergé.-

Boost list run by bdawes at, gregod at, cpdaniel at, john at