Date: Fri, 7 Mar 2025 09:22:18 +0000
> Come on now. There�s an actual RFC that describes how to do this very thing�linked in the proposal.
I'm not joking. There's nothing that guarantees that the clock has enough precision to give you 2 different values when called twice. Which defeats the purpose
of being "Unique", it would be everything else but the time that would have to pull the work of making it unique.
At that point you might as well just get a random number.
________________________________
From: Nikolaos D. Bougalis <nikb_at_[hidden]>
Sent: Friday, March 7, 2025 9:49:24 AM
To: Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock
On Fri, Mar 7, 2025 at 02:03, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:On%20Fri,%20Mar%207,%202025%20at%2002:03,%20Tiago%20Freire%20via%20Std-Proposals%20<<a%20href=>> wrote:
The simplest solution would be to just create a shell script that generates a file with the current time, let the build system call that shell script before build, and then not touch the compiler.
That's what I do (and I don't think I'm the only one).
Not everything needs to be a feature of the compiler.
Certainly there�s a ton of things one can do as part of the build process, with tools and scripts and whatnot, and that�s the situation a lot of us find ourselves in.
It would be nice to be able to do some of these things in C++, but I agree that not everything needs to be a feature of the compiler (or the language). I still think this is a reasonable proposal (albeit not without its issues�the ODR comments have got me thinking) and will try to refine it, but I�m ok if the consensus is that this belongs in the trash.
As for UUID. A time stamp is not a reliable way to create a UUID, so I'm not even going to bother with that use case.
Come on now. There�s an actual RFC that describes how to do this very thing�linked in the proposal. It�s one thing if you don�t care to do this or even if you don�t think that it�s important to do be able to do it at compile time, but this particular response is just silly.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jan Schultke via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, March 7, 2025 7:19:32 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jan Schultke <janschultke_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock
I've got a much simpler alternative idea: we could say that every clock has a
> static constinit const time_point translation_time;
... data member. There is no potential for ODR violations because you
cannot access it during constant evaluation anyway. It's simply saying
that you're baking the timestamp into the executable. The linker could
still optimize it out if it's unused.
I'm not joking. There's nothing that guarantees that the clock has enough precision to give you 2 different values when called twice. Which defeats the purpose
of being "Unique", it would be everything else but the time that would have to pull the work of making it unique.
At that point you might as well just get a random number.
________________________________
From: Nikolaos D. Bougalis <nikb_at_[hidden]>
Sent: Friday, March 7, 2025 9:49:24 AM
To: Nikolaos D. Bougalis via Std-Proposals <std-proposals_at_[hidden]>
Cc: Tiago Freire <tmiguelf_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock
On Fri, Mar 7, 2025 at 02:03, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]<mailto:On%20Fri,%20Mar%207,%202025%20at%2002:03,%20Tiago%20Freire%20via%20Std-Proposals%20<<a%20href=>> wrote:
The simplest solution would be to just create a shell script that generates a file with the current time, let the build system call that shell script before build, and then not touch the compiler.
That's what I do (and I don't think I'm the only one).
Not everything needs to be a feature of the compiler.
Certainly there�s a ton of things one can do as part of the build process, with tools and scripts and whatnot, and that�s the situation a lot of us find ourselves in.
It would be nice to be able to do some of these things in C++, but I agree that not everything needs to be a feature of the compiler (or the language). I still think this is a reasonable proposal (albeit not without its issues�the ODR comments have got me thinking) and will try to refine it, but I�m ok if the consensus is that this belongs in the trash.
As for UUID. A time stamp is not a reliable way to create a UUID, so I'm not even going to bother with that use case.
Come on now. There�s an actual RFC that describes how to do this very thing�linked in the proposal. It�s one thing if you don�t care to do this or even if you don�t think that it�s important to do be able to do it at compile time, but this particular response is just silly.
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Jan Schultke via Std-Proposals <std-proposals_at_[hidden]>
Sent: Friday, March 7, 2025 7:19:32 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Jan Schultke <janschultke_at_[hidden]>
Subject: Re: [std-proposals] constexpr support for std::chrono::system_clock
I've got a much simpler alternative idea: we could say that every clock has a
> static constinit const time_point translation_time;
... data member. There is no potential for ODR violations because you
cannot access it during constant evaluation anyway. It's simply saying
that you're baking the timestamp into the executable. The linker could
still optimize it out if it's unused.
-- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-03-07 09:22:24