On Wednesday, 2 September 2020 00:15:37 PDT Mathias Hasselmann wrote: > I'd rather say that cast is entirely ugly. Seems like a perfect example > or code smell: Something is fundamentally wrong they way qsizetype is > defined.
Lars has asked for qsizetype to be defined as the same type (not just the same size) as ptrdiff_t. Effectively, this means defining qint64 as the same type as int64_t. Sounds easy, right? Please remember that qlonglong is the same type in Qt as qint64. That means on these platforms, qlonglong would then be "long", not "long long". This is also reflected in our API: QString::toLongLong and QVariant::toLongLong -- will they return long? Those types are probably also used in a lot of overload sets and could break existing code. Moreover, it could make maintaining Qt5 and Qt6 codebases working together cumbersome. I'm not completely opposed to changing this. But I am asking whether it's worth the trouble. Tor Arne wrote: > As a user of this API I was also stumped by not being able to just call > printf with %z and a qsizetype, under the assumption that qsizetype’s > purpose in life was to mask _away_ the differences of what a size was > represented as. That is indeed why C99 added the "z" and "t" modifiers. But unfortunately we still support one pre-C99 runtime, so you can't use them in cross-platform code. For restricted scenarios (MSVC-only or Unix-only code), you can use those modifiers. And in MSVC-only scenarios, there will be no type mismatch either, in both 32- and 64-bit. On 64-bit Unix, the result will be correct too, since the types are the right size. The only thing is you may get a compiler warning that the types mismatched. We could disable -Wformat. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
