[Development] <chrono> first (was: Re: C++20 @ Qt)

Thiago Macieira thiago.macieira at intel.com
Mon Jan 23 23:57:42 CET 2023

On Monday, 23 January 2023 05:06:13 PST Marc Mutz via Development wrote:
> Instead of changing to qint64 timeouts, as suggested, we should use
> chrono types. Here's why:
> - we do have QDeadlineTimer, which implicitly converts from chrono
>    types, but
>    - it has a Forever state, which is meaningful for timeouts, but not
>      for intervals (QTimer with Forever interval?).

In other words, use the std::chrono::duration types but not the 
std::chrono::time_point types.

> - if we take qint64, then internally have to construct a chrono type
>    from it, it means Qt code is responsible for checking for overflow
>    (chrono::milliseconds need not support the full 64-bit range),
>    creating an artificial error state that wouldn't exist if we only
>    accepted chrono types.

Add to qglobal.cpp:
static_assert(sizeof(std::chrono::milliseconds::rep) == 8);

We should do this anyway.

> So, chrono types are
> - more future-proof
> - safer (both as in less possible errors in the implementation, as well
>    as more type-safe in the caller)
> - self-explanatory (w.r.t. granularity)
> - more expressive


> So, I suggest to port all duration-related APIs to <chrono>, and make
> <chrono> the primary implementation, not vice versa. In any case, ndo ot
> add 64-bit timeouts (ns granularity like QDeeadlineTimer is ok, because
> std::chrono::nanoseconds has at least a 64-bit representation). Do not
> add new integer-based duration properties. Use QDeadlineTimer if
> 'Forever' is a valid value (e.g. timeouts).


Thanks for bringing this up in the mailing list.

Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5167 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230123/59ce7f7c/attachment-0001.bin>

More information about the Development mailing list