On Thu, 20 Apr 2023, 16:10 Thiago Macieira via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Thursday, 20 April 2023 04:49:51 PDT Jonathan Wakely via Std-Proposals
> wrote:
> > 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.
>