On 4/20/23 13:12, Jonathan Wakely wrote:
>
>
> On Thu, 20 Apr 2023 at 08:45, Andrey Semashev via Std-Proposals
> <std-proposals@lists.isocpp.org <mailto:std-proposals@lists.isocpp.org>>
> wrote:
>
> I wanted to say that I faced this problem as well, and my solution was
> to define clock traits that, among other things, allowed to know the
> clockid_t corresponding to a given chrono clock.
>
> User code can't know this, certainly not as a compile-time constant. It
> might depend on runtime conditions, such as the kernel version the
> application runs on, and the system config.
Well, all kernel versions we cared to support do support
CLOCK_MONOTONIC,
As Thiago mentioned, chrono::steady_clock could potentially use CLOCK_MONOTONIC_RAW, and the decision to use it could be made at runtime (by trying it once and if the syscall returns ENOSYS using CLOCK_MONOTONIC for all future calls).
and CLOCK_REALTIME is mandatory on all POSIX systems.
But even that isn't always used, and the decision of whether to use it might depend on the version of the std::lib that you dynamically link to at runtime:
A compile-time constant in the headers cannot accurately represent that behaviour.