[Development] Is qsizetype *documented* to be ptrdiff_t?
Giuseppe D'Angelo
giuseppe.dangelo at kdab.com
Thu Sep 3 06:37:23 CEST 2020
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&matching types in the APIs rather than
streamlining.
My 2 c,
--
Giuseppe D'Angelo | giuseppe.dangelo at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200903/a6ad5a41/attachment.bin>
More information about the Development
mailing list