[Development] <chrono> first (was: Re: C++20 @ Qt)
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
> - 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...
Size: 5167 bytes
Desc: not available
More information about the Development