On 09/01/2014 05:06 a.m., Oliver Kowalke wrote:
2014/1/9 Agustín K-ballo Bergé
- 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