Le 26/07/14 22:09, Agustín K-ballo Bergé a écrit :
On 26/07/2014 03:02 p.m., Ian Forbes wrote:
This defaults to `boost::chrono::steady_clock`. There is a static assert to ensure that `Clock` is steady.
Given that you restrict everything to steady clocks, What's the rationale for restricting to a single `time_point` instantiation only? Furthermore, restricting to a single `duration` makes absolutely no sense. Any `duration` can be mapped to a steady `time_point` and still meet the timing specifications.
This seems to be a popular request. I will look into it.
I am not surprised. Note that proper Chrono support is trivial for any Clock for all your timed operations but some of those involving a `sync_timed_queue`.
You may wanna read the following http://talesofcpp.fusionfenix.com/post-15/rant-on-the-templated-nature-of-st... . It was partly motivated by the poor choices made by the executors proposal. Thanks for this pointer. Really very interesting.
There is a type here auto d = std::chrono::conversion_caststd::chrono::nanoseconds(rel_time);
This is also satisfied by `high_resolution_clock` (...) It is not.
(...) is no longer a factor like with `steady_clock` and `high_resolution_clock` which are wall clocks.
They are not (or may not be). The only guarantees are that `system_clock` represents a wall clock, `steady_clock` represents a clock that may not be adjusted, `high_resolution_clock` represents a clock with the shortest tick period. In particular, `steady_clock` and `high_resolution_clock` may be aliases for other clocks.
It's not guaranteed but I would assume it is steady for most modern machines.
Sorry, but that's not how it works. You can't base your work on assumptions nor observations, only guarantees. In particular, your observations don't hold for other platforms; and then there's the broken platforms where clocks pretend to be steady when in reality they are not.
You have already correctly identified that any implementation has to be based on a steady clock (kudos! the executors proposal got this wrong). Once you have a steady clock, you can support timed operations for all `duration`s, and all `time_point`s of any other steady clock. In order to support `time_point`s of non-steady clocks too, it would be enough to meet the standard timing specifications to wrap the closure into a helper task that checks if the timeout is already satisfied, and reschedules the closure otherwise (this may not be trivial, I haven't looked at your implementation in detail).
There is one and only one standard clock that is guaranteed to be steady, and that is the `steady_clock`. Build your implementation on top of it. Don't provide the user a way to specify the implementation Clock, provide the proper interface instead. If there happens to be a better choice than `steady_clock` for a particular platform (I'm not saying there is), and said clock is **guaranteed** to be steady, then the decision to use it should belong to the library and not the user.
+1 for all your remarks. Vicente