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.
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. For example: #include <iostream> #include <boost/chrono.hpp> using namespace boost::chrono; int main() { std::cout << system_clock::is_steady << std::endl; std::cout << steady_clock::is_steady << std::endl; std::cout << high_resolution_clock::is_steady << std::endl; std::cout << process_user_cpu_clock::is_steady << std::endl; std::cout << process_system_cpu_clock::is_steady << std::endl; std::cout << process_real_cpu_clock::is_steady << std::endl; std::cout << thread_clock::is_steady << std::endl; } Outputs this for me on Linux 3.13 with a Core2 cpu. 0 1 1 1 1 1 1 That means I can essentially pick from 6 clocks. And the cpu/thread clocks might be useful.
I've glanced at the code, and noticed that `time_point`s and `duration`s are taken by value. The standard takes them by `const&` so I think you should follow that.
This is an oversight on my part. I will fix this. Ian,