On Thu, 20 Apr 2023, 16:10 Thiago Macieira via Std-Proposals, <std-proposals@lists.isocpp.org> wrote:
On Thursday, 20 April 2023 04:49:51 PDT Jonathan Wakely via Std-Proposals
> 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/c
> hrono.cc;h=8f869df5696473ebd0157e9edb4875af8c1381ce;hb=HEAD#l50
> A compile-time constant in the headers cannot accurately represent that
> behaviour.

Strictly speaking, it *can* represent the behaviour of the link above, so long
as libstdc++ decides that the clock source is ABI. The constant can be added
to bits/c++config.h, which is a compile-time generated header.

It's generated when gcc is compiled, which is too early for some decisions.

So long as the
operating system itself doesn't regress, all new builds should have the same
macros defined.

The way it works today, you can compile the code with an older GCC or a GCC built on an older system that doesn't support clock_gettime, then run the program on a newer system with a newer libstdc++.so where the library uses clock_gettime. A clock macro/constant in the header that was seen at compile time would not match what actually happened at runtime.

So adding such a constant to the header would prevent the library from using the "best" clock available. As you say, it would be an ABI artefact and so "frozen". I don't think that would be a good idea. We should avoid turning things into unchangeable ABI decisions if we can help it.

We'll see when the discussion on CLOCK_MONOTONIC_RAW concludes whether it is
right to be ABI. Right now, there may be code that depends on steady_clock
being CLOCK_MONOTONIC; making a change could result in subtly broken code
because of the micro- to millisecond-wide difference between the two clocks.