Boost logo

Boost :

Subject: Re: [boost] Boost.Fiber mini-review September 4-13
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-09-04 15:35:38


On 9/4/2015 4:13 PM, Oliver Kowalke wrote:
> 2015-09-04 21:05 GMT+02:00 Agustín K-ballo Bergé <kaballo86_at_[hidden]>:
>
>> On 9/4/2015 3:46 PM, Nat Goodspeed wrote:
>>
>>> On Fri, Sep 4, 2015 at 2:24 PM, Agustín K-ballo Bergé
>>> <kaballo86_at_[hidden]> wrote:
>>>
>>> I just had a quick look at the future implementation, to see if proper
>>>> chrono support (one of the reasons for my previous rejection) was
>>>> implemented. While `wait_for` depicts the standard signature, it does not
>>>> seem `wait_until` does.
>>>>
>>>
>>> I want to make it as easy as possible for Oliver to act on people's
>>> feedback. Please suggest a specific change?
>>>
>>
>> That would be:
>>
>> "- Every API involving time point or duration should accept arbitrary
>> clock types, immediately converting to a canonical duration type for
>> internal use."
>>
>
> future<> has an overload for wait_until()
>
> template< typename ClockType >
> future_status wait_until( typename ClockType::time_point const&) const;

Here is the standard definition of `future::wait_until`:

     template <class Clock, class Duration>
     future_status wait_until(chrono::time_point<Clock, Duration> const&
abs_time) const;

Note how it takes *any* time point, and automatically deduces template
arguments.

Yours requires explicitly specifying a clock type, and not all possible
time points necessarily have a corresponding clock type readily available.

Regards,

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

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