[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