[Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

[Marco Bubke]

One solution would be std::ssize(vectorWithSignedSize) == std::ssize(vectorWithUnsignedSize) where you always get ssize_t back. This is proposed for C++20. You can write your own version if you want.

________________________________
From: Development <development-bounces at lists.qt-project.org> on behalf of Bernhard Lindner <private at bernhard-lindner.de>
Sent: Tuesday, December 4, 2018 5:35:58 PM
To: development at lists.qt-project.org
Subject: Re: [Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

Hi!

> You're inverting the argument we've had for using int.

Yes, because I have other priorities.

> It's not that it's
> always sufficient, but it's sufficient for a sufficient number of use-cases,
> thus avoiding unnecessary casts *and* avoiding mistakes in conversion.

Avoiding cast? Creating casts! I rarly need to cast unsigned sizes to signed in a
compliant environment. But I need a LOT of casts whenever integrating Qt with compliant
code.

Whoever ignores standards is the one who creates interfacing effort. And Qt is
(unnecessarily) ignoring standards. If the world would consit of Qt only, then maybe you
would be right. But most of the world is not Qt.

Using int instead of size_t (or a compatible type) for me means: More unit tests, more
error checks and asserts, more documentation, more document reading, lots of casts when interfacing standard compliant code. All due to the negative value range.

> The literal "1" is int, not size_t or long, so i,'s far easier to write int
> code than size_t.

You think this is a strong argument?

> In any case, Qt will not use an unsigned type.

So qsizetype will be signed in Qt6?

What a pitty. I assumed the non-compliant int usage would be some legacy burden and hoped
it would be fixed at the earliest opportunity.

Anyway the usage of qsizetype would be an improvment.

--
Best Regards,
Bernhard

_______________________________________________
Development mailing list
Development at lists.qt-project.org
https://lists.qt-project.org/listinfo/development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181204/7eb48cd8/attachment.html>