On 08/01/2014 12:20 p.m., Nat Goodspeed wrote:
On Wed, Jan 8, 2014 at 9:02 AM, Hartmut Kaiser
wrote: One of the main questions arising for me when looking through the code is why doesn't the fiber class expose the same API as std::thread (or boost::thread for that matter)? This would make using fibers so much more usable, even more as the rest of the library was aligned with the C++11 standard library.
To the best of my knowledge, Oliver is indeed trying to mimic the std::thread API. It would be very helpful if you would point out the deltas that you find distressing.
Just from looking at the documentation: - The constructor takes a nullary function, instead of a callable and an arbitrary number of parameters. It is not clear whether Fn has to be a function object or if it can be a callable as with std::thread. The order of parameters of the overload taking attributes does not match that of boost::thread. - No notion of native_handle (this may not make sense for fibers, I haven't looked at the implementation). - There is no notion of explicit operator bool in neither boost::thread nor std::thread. - 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. - Several functions take a fixed time_point type instead of a chrono one. - There is no indication whether the futures support void (I assume they do) and R& (I assume they don't). The return type for shared_future::get is wrong. Again, there's additional explicit operator bools. - The documentation for promise doesn't seem to support void, it is unclear whether they support references. Another explicit operator bool. - I saw mentions of async in the documentation, but I couldn't find the actual documentation for it. It's not clear whether deferred futures are supported, at least they appear not to be from future's reference. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com