Hi,
TL;DR:
- don't use qin64 for durations
- use QDeadlineTimer for timeouts
- use chrono::{milli,micro,nano,}seconds for everything that doesn't have
Forever state
- don't implement chrono via integer overloads, do it the other way around
Not really C++20, rather C++11, but let's keep the C++ stuff together.
Since 2018, in QTBUG-67383, we have users complaining about the limited
range of int milliseconds arguments:
> Now QTimer::start(int msec) accepts only int values which corresponds
> to ~ 24 days as maximum time interval.
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?).
- it's name doesn't exactly lend itself for use in APIs (why pass a
timer to a timer?)
- it always has nanosecond resolution. Most of our APIs have
millisecond resolution. Unless we want to change them all to ns
resolution, any function using QDT must document the real
granularity of the duration, and the rounding mode from ns. In
contrast, passing 1ns to a function taking chrono::milliseconds
simply fails to compile,forcing the caller to be explicit about what
he wants (chrono::floor, chrono::ceil, duration_cast, ...).
- we do support chrono types in many APIs, and we want to support them
in all APIs that deal with duration, as 1s is just so much more expressive
than '1000'. The integer-based APIs should be considered legacy
support. At some point, we might want to deprecate them, and then the
chrono overloads become the main implementation, anyway, so we might
just go there directly.
- 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.
- if we take a chrono type, then shoehorn it through a legacy int
overload, we lose the range provided by the chrono types and
requested by users
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).
There's no rush, we need to get the plumbing in QtCore right, first.
Comments?
Thanks,
Marc
--
Marc Mutz <marc.m...@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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
