[Development] <chrono> first (was: Re: C++20 @ Qt)
Marc Mutz
marc.mutz at qt.io
Thu Jan 26 15:46:19 CET 2023
On 24.01.23 17:03, Thiago Macieira wrote:
> On Tuesday, 24 January 2023 00:44:37 PST Marc Mutz via Development wrote:
>> On 23.01.23 23:57, Thiago Macieira wrote:
>>> static_assert(sizeof(std::chrono::milliseconds::rep) == 8);
>>
>> Why == and not >=?
>
> I think we'd want to know if that happened,
There is a difference between "knowing that it happened" and "requiring
that it not be so".
> because a lot of our code will be
> depending on the ± 292 million years limit around the epoch.
Then we should strive to avoid falling into the trap of Hyrum's Law and
make sure we only depend on what the standard promises :)
If a platform wants to use int128 for std::chrono::milliseconds::rep,
then we shouldn't be standing in its way (yes, that means keeping chrono
types around and not dropping to integers at the first option, but
that's what chrono-first is all about).
That said, QDeadlineTimer _is_ a problem, since it doesn't contain
std::chrono::nanoseconds, but a qint64.
So maybe we should, indeed, release a Qt with that static_assert (using
==) once, and then replace the all the qint64's (in QDeadlineTimer and otherwise) with std::chrono types, knowing
we didn't change anything, then drop the static_assert again, inviting
such future implementations (RISC-V already standardized a 128-bit
architecture).
Thanks,
Marc
--
Marc Mutz <marc.mutz at qt.io>
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
More information about the Development
mailing list