On Thu, 20 Apr 2023 at 11:55, Andrey Semashev via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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,


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:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/chrono.cc;h=8f869df5696473ebd0157e9edb4875af8c1381ce;hb=HEAD#l50

A compile-time constant in the headers cannot accurately represent that
behaviour.