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 <[email protected]> on behalf of 
Bernhard Lindner <[email protected]>
Sent: Tuesday, December 4, 2018 5:35:58 PM
To: [email protected]
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
[email protected]
https://lists.qt-project.org/listinfo/development
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development

Reply via email to