Date: Thu, 20 Apr 2023 13:55:04 +0300
On 4/20/23 13:12, Jonathan Wakely wrote:
>
>
> On Thu, 20 Apr 2023 at 08:45, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> 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, and CLOCK_REALTIME is mandatory on all POSIX systems.
But you have a point for other clock types.
>
>
> On Thu, 20 Apr 2023 at 08:45, Andrey Semashev via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>>
> 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, and CLOCK_REALTIME is mandatory on all POSIX systems.
But you have a point for other clock types.
Received on 2023-04-20 10:55:07