Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On Wednesday, 2 September 2020 23:54:35 PDT Lars Knoll wrote: > I think we have long in most of the important places today. I agree that > adding long to the overload set is somewhat annoying, but it could be an > inline method mapping to QIntegerForSize::type. > > Has anybody ever looked how many places we would actually have problems with > that? I doubt it’s that many. That's adding support for long without changing QIntegerForSize, which in turn defines what qsizetype is. As I said, I oppose qint64 and qsizetype not being the same type on 64-bit platforms. If we change this, then our overload set goes from typedefs to the basic ones: int, long and long long. Don't use int64_t or size_t or qint64 or qsizetype. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On Thursday, 3 September 2020 04:14:06 PDT Giuseppe D'Angelo via Development wrote: > Interestingly enough, QDataStream is defined in terms of qintXX types > (and it's missing long), QTextStream in terms of native datatypes (and > has them all). Intentionally! Because long changes size across platforms. So you must choose whether to encode your value as 32-bit or as 64-bit, explicitly. Note that this now applies to qsizetype and we don't have the same protection. You must choose the size and the compiler won't tell you if you forgot. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On 03/09/2020 08:54, Lars Knoll wrote: I think we have long in most of the important places today. I agree that adding long to the overload set is somewhat annoying, but it could be an inline method mapping to QIntegerForSize::type. Has anybody ever looked how many places we would actually have problems with that? I doubt it’s that many. A few? * QDataStream Interestingly enough, QDataStream is defined in terms of qintXX types (and it's missing long), QTextStream in terms of native datatypes (and has them all). * QString/QByteArray My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
> On 3 Sep 2020, at 07:06, Thiago Macieira wrote: > > On Wednesday, 2 September 2020 21:37:23 PDT Giuseppe D'Angelo via Development > wrote: >> On 03/09/2020 06:08, Thiago Macieira wrote: >>> Because qsizetype is the same type as qint64, which is the same type as >>> qlonglong (which exists for historical reasons, because older VC++ didn't >>> support "long long"). >> >> I'm very sorry, I'm lost now -- are you using as a postulate "on 64 bit >> systems"? I would've expected qsizetype to be 32 bits (on 32 bit systems)... > > Yes, the issue only happens on 64-bit Unix systems. > > On 64-bit Windows and on all 32-bit systems, qsizetype and ptrdiff_t types > match. > >> But while qint64 should not change / still be the same type of >> qlonglong, why qsizetype has to be the same type qint64 and cannot be a >> different type (say, ptrdiff_t)? > > qsizetype x = QRandomGenerator::system()->bounded(list.size()); > > See https://bugreports.qt.io/browse/QTBUG-86318 > > If we use all three types in Qt (int, long and long long), then we need all > three in all the overload sets. Today we have int/qlonglong or qint32 / > qint64 > overload sets, with a few exceptions also adding long. I think we have long in most of the important places today. I agree that adding long to the overload set is somewhat annoying, but it could be an inline method mapping to QIntegerForSize::type. Has anybody ever looked how many places we would actually have problems with that? I doubt it’s that many. Cheers, Lars > >>> qint64 v = QRandomGenerator::system()->bounded(str.toLongLong()); >>> >>> Does this compile or not? >> >> Devil's advocate: next to "toLongLong", why there isn't also "toInt64"? > > Because there's no toInt32 and toInt16 either. They can be added, or better > yet we can use templates (toInteger), but this API doesn't exist yet. > >> Or why does bounded() take int64, not long long? Do we have a policy on >> which one to use where? This smells like we're making the situation >> worse by increasing the mix types in the APIs rather than >> streamlining. > > Because most people want to add two functions to their overload sets: int / > qlonglong or qint32 / qint64. By matching size_t / ptrdiff_t, we'll need to > expand all those overload sets to three. > > Note: bounded() currently does not take any 64-bit type at all; only 32-bit. > See task above to add the 64-bit ones. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel DPG Cloud Engineering > > > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On Wednesday, 2 September 2020 21:37:23 PDT Giuseppe D'Angelo via Development wrote: > On 03/09/2020 06:08, Thiago Macieira wrote: > > Because qsizetype is the same type as qint64, which is the same type as > > qlonglong (which exists for historical reasons, because older VC++ didn't > > support "long long"). > > I'm very sorry, I'm lost now -- are you using as a postulate "on 64 bit > systems"? I would've expected qsizetype to be 32 bits (on 32 bit systems)... Yes, the issue only happens on 64-bit Unix systems. On 64-bit Windows and on all 32-bit systems, qsizetype and ptrdiff_t types match. > But while qint64 should not change / still be the same type of > qlonglong, why qsizetype has to be the same type qint64 and cannot be a > different type (say, ptrdiff_t)? qsizetype x = QRandomGenerator::system()->bounded(list.size()); See https://bugreports.qt.io/browse/QTBUG-86318 If we use all three types in Qt (int, long and long long), then we need all three in all the overload sets. Today we have int/qlonglong or qint32 / qint64 overload sets, with a few exceptions also adding long. > >qint64 v = QRandomGenerator::system()->bounded(str.toLongLong()); > > > > Does this compile or not? > > Devil's advocate: next to "toLongLong", why there isn't also "toInt64"? Because there's no toInt32 and toInt16 either. They can be added, or better yet we can use templates (toInteger), but this API doesn't exist yet. > Or why does bounded() take int64, not long long? Do we have a policy on > which one to use where? This smells like we're making the situation > worse by increasing the mix types in the APIs rather than > streamlining. Because most people want to add two functions to their overload sets: int / qlonglong or qint32 / qint64. By matching size_t / ptrdiff_t, we'll need to expand all those overload sets to three. Note: bounded() currently does not take any 64-bit type at all; only 32-bit. See task above to add the 64-bit ones. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On 03/09/2020 06:08, Thiago Macieira wrote: Because qsizetype is the same type as qint64, which is the same type as qlonglong (which exists for historical reasons, because older VC++ didn't support "long long"). I'm very sorry, I'm lost now -- are you using as a postulate "on 64 bit systems"? I would've expected qsizetype to be 32 bits (on 32 bit systems)... But while qint64 should not change / still be the same type of qlonglong, why qsizetype has to be the same type qint64 and cannot be a different type (say, ptrdiff_t)? I don't have a problem changing the actual type those are aliases of. But I do have a problem making them different types. A lot of code assumes that qint64 and qlonglong are the same type. While they're always the same size, having them be different types could result in warnings and problems with overload sets. For example, say I've added QRandomGenerator::bounded(qint64) and quint64. qint64 v = QRandomGenerator::system()->bounded(str.toLongLong()); Does this compile or not? Devil's advocate: next to "toLongLong", why there isn't also "toInt64"? Or why does bounded() take int64, not long long? Do we have a policy on which one to use where? This smells like we're making the situation worse by increasing the mix types in the APIs rather than streamlining. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On Wednesday, 2 September 2020 19:25:39 PDT Giuseppe D'Angelo via Development wrote: > I'm lacking some context here, why does the definition of qsizetype > affect toLongLong? I would imagine that toLongLong functions deal with > "long long" no matter what. Why does this prevent making qsizetype == > ptrdiff_t? Because qsizetype is the same type as qint64, which is the same type as qlonglong (which exists for historical reasons, because older VC++ didn't support "long long"). I don't have a problem changing the actual type those are aliases of. But I do have a problem making them different types. A lot of code assumes that qint64 and qlonglong are the same type. While they're always the same size, having them be different types could result in warnings and problems with overload sets. For example, say I've added QRandomGenerator::bounded(qint64) and quint64. qint64 v = QRandomGenerator::system()->bounded(str.toLongLong()); Does this compile or not? > > 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. > > We're proposing every now and then to drop compilers and platforms for > much less, but we do bother with supporting a toolchain that still > doesn't implement 20+ years old standards? What's the percentage of > users of that one? Since we're talking about MinGW, I think it's considerable. I've done some research on this, though not as deeply as is required to come to a conclusion. MinGW can use one of three printf family implementations: - the default: msvcrt.dll / crtdll.dll, which is effectively unchanged since Windows 95 (even the 64-bit version, which was first released in 2005) - the one in libmingwex-0.dll - the Windows 10 Universal CRT The default has the advantage that it is present on every single Windows system, so there's no extra DLL that one needs to ship. The Universal CRT is the long-term solution, but clearly requires Windows 10. The portable MinGW extension library can be used to get a modern runtime on older Windows. Except that UCRT is not completely supported yet. The compiler itself needs to be patched to pass a different set of libraries to the linker. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On 02/09/2020 16:49, Thiago Macieira wrote: 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. I'm lacking some context here, why does the definition of qsizetype affect toLongLong? I would imagine that toLongLong functions deal with "long long" no matter what. Why does this prevent making qsizetype == ptrdiff_t? 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. We're proposing every now and then to drop compilers and platforms for much less, but we do bother with supporting a toolchain that still doesn't implement 20+ years old standards? What's the percentage of users of that one? 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. That sounds evil. It catches real bugs (just caught https://codereview.qt-project.org/c/qt/qtbase/+/299726 ). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On Wed, Sep 02, 2020 at 09:15:37AM +0200, 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. Funnily enough the same can be said for the casts that are now necessary in a formerly consistent 'int'-based codebase using Qt containers. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
> On 2 Sep 2020, at 16:49, Thiago Macieira wrote: > > 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. > > 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. Right, I was talking about the fact that even using %z will give you a warning, which seems counter to the assumed promise that qsizetype is a generic size type that masks away the platform differences. I’d expect one of the things it would do well, from an API/usability pov, is to be printable with the “size” format specifier Today you need printf(“%z\n”, size_t(foo.size())); Cheers, Tor Arne ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
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 Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
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.
Since it all flattens down to e.g. qint64 I don’t suppose there’s anything we
can do to make the %z case less confusing by adding convenience for size_t? If
not a doc update would be helpful at least.
Cheers,
Tor Arne
> On 2 Sep 2020, at 09:15, 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.
>
> Am 01.09.2020 um 19:29 schrieb Thiago Macieira:
>> On Tuesday, 1 September 2020 08:44:07 PDT Giuseppe D'Angelo via Development
>> wrote:
>>> Il 01/09/20 16:23, Thiago Macieira ha scritto:
So even if you use %td or %zd, GCC will complain in one of three different
platform configurations (namely, 64-bit Unix).
>>> Pedantically, do we need the PRIxQSS (?) macro and friends to use
>>> qsizetype into qWarning etc.?
>> That's ugly. Just cast the type itself to ptrdiff_t or int.
>>
>> That is, write:
>>
>> qWarning("List too big: %zd", ptrdiff_t(list.size());
>>
>> Qt's internal sprintf-like functions actually use qsizetype, not ptrdiff_t,
>> so
>> pedantically-strictly speaking the compiler is wrong and your code was right
>> without the cast. In real-life, it just works.
>>
>> Note: this only applies to the functions that actually use Qt's own sprintf-
>> like functions. You can't use with printf family itself because we still
>> support MinGW and that one uses a C99-incompatible standard library by
>> default
>> (no "z" and no "t" modifier and no 64-bit support on 32-bit systems).
>>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
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.
Am 01.09.2020 um 19:29 schrieb Thiago Macieira:
On Tuesday, 1 September 2020 08:44:07 PDT Giuseppe D'Angelo via Development
wrote:
Il 01/09/20 16:23, Thiago Macieira ha scritto:
So even if you use %td or %zd, GCC will complain in one of three different
platform configurations (namely, 64-bit Unix).
Pedantically, do we need the PRIxQSS (?) macro and friends to use
qsizetype into qWarning etc.?
That's ugly. Just cast the type itself to ptrdiff_t or int.
That is, write:
qWarning("List too big: %zd", ptrdiff_t(list.size());
Qt's internal sprintf-like functions actually use qsizetype, not ptrdiff_t, so
pedantically-strictly speaking the compiler is wrong and your code was right
without the cast. In real-life, it just works.
Note: this only applies to the functions that actually use Qt's own sprintf-
like functions. You can't use with printf family itself because we still
support MinGW and that one uses a C99-incompatible standard library by default
(no "z" and no "t" modifier and no 64-bit support on 32-bit systems).
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On Tuesday, 1 September 2020 08:44:07 PDT Giuseppe D'Angelo via Development
wrote:
> Il 01/09/20 16:23, Thiago Macieira ha scritto:
> > So even if you use %td or %zd, GCC will complain in one of three different
> > platform configurations (namely, 64-bit Unix).
>
> Pedantically, do we need the PRIxQSS (?) macro and friends to use
> qsizetype into qWarning etc.?
That's ugly. Just cast the type itself to ptrdiff_t or int.
That is, write:
qWarning("List too big: %zd", ptrdiff_t(list.size());
Qt's internal sprintf-like functions actually use qsizetype, not ptrdiff_t, so
pedantically-strictly speaking the compiler is wrong and your code was right
without the cast. In real-life, it just works.
Note: this only applies to the functions that actually use Qt's own sprintf-
like functions. You can't use with printf family itself because we still
support MinGW and that one uses a C99-incompatible standard library by default
(no "z" and no "t" modifier and no 64-bit support on 32-bit systems).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel DPG Cloud Engineering
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
Il 01/09/20 16:23, Thiago Macieira ha scritto: So even if you use %td or %zd, GCC will complain in one of three different platform configurations (namely, 64-bit Unix). Pedantically, do we need the PRIxQSS (?) macro and friends to use qsizetype into qWarning etc.? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
On Monday, 31 August 2020 04:55:32 PDT Giuseppe D'Angelo via Development wrote: > Quick question (before Hyrum's law kicks in): qsizetype is currently > defined as ptrdiff_t, but is it documented to be so? > > For instance, is one supposed to print it in printf using %td? It's always the same size as ptrdiff_t so you can cast to ptrdiff_t and never lose any data, before calling printf-like functions. In fact, it's defined to be a signed integer the same size as size_t, so the correct printf template is %zd, but that's being pedantic since ptrdiff_t is always the signed counterpart to size_t in all known platforms. But it's not the same type as ptrdiff_t. The latter can assume one of three different types but qsizetype can only be two: ptrdiff_t qsizetype int int long long long long long So even if you use %td or %zd, GCC will complain in one of three different platform configurations (namely, 64-bit Unix). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Is qsizetype *documented* to be ptrdiff_t?
> On 31 Aug 2020, at 13:55, Giuseppe D'Angelo via Development > wrote: > > Quick question (before Hyrum's law kicks in): qsizetype is currently defined > as ptrdiff_t, but is it documented to be so? It is defined as qint64, which is not always ptrdiff_t. I proposed to Thiago to change that, but he has some concerns. As far as I understood, the main issue is that ptrdiff_t is long on some platforms and long long on others. One issue with that is that we traditionally didn’t provide overloads for long for methods like QString::number() etc. > > For instance, is one supposed to print it in printf using %td? Right not, you need to cast to ptrdiff_t and then use %td. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
