C++ Logo

std-proposals

Advanced search

Re: [std-proposals] constexpr support for std::chrono::system_clock

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Fri, 7 Mar 2025 01:10:14 +0000
On Fri, 7 Mar 2025, 00:32 Nikolaos D. Bougalis via Std-Proposals, <
std-proposals_at_[hidden]> wrote:

> On Thursday, March 6th, 2025 at 16:03, Marc Edouard Gauthier <
> MarcEdouard.Gauthier_at_[hidden]> wrote:
>
> > If this were done, I’d expect it to be a new function, maybe named
> compile_time().
>
> The proposal briefly discusses that. I don't think having a separate
> function makes sense.
>
>
> > And I would certainly not assume it enables timing compilation time,
> that’s not necessarily how a compiler works evaluating its constexpr
> expressions.
>
> I don't know the finer details of how compilers evaluate constexpr
> expressions, and perhaps the idea of timing constexpr code is bunk, but
> even if it is, there are other good reasons (imo) to have the capability.
>
>
> >Of course some compiler option probably disables it or makes it return a
> defined value or such, for those who need reproducible builds.
>
> Pardon me, but you're the second person to raise objections vis-à-vis
> reproducible builds and I must confess I am confused.
>
> Even if this functionality were added, it would not affect reproducible
> builds in _any_ way, _unless the developers of the software chose to use
> it_! Given that it is largely incompatible with reproducible/deterministic
> builds, why would they?
>

The people writing the code might not be the ones compiling it. Linux
distros want reproducible builds, and it's a problem if that's impossible
because some software they want to package insists on using clocks and
there's no way to override the time (the way there is for __TIME__).

I assure you that reproducible builds are important.



>

Received on 2025-03-07 01:10:32