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 Agreed. > 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). Agreed. Thanks for bringing this up in the mailing list. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
