[Interest] Operator QMap<uint, uint> is casting to int?
giuseppe.dangelo at kdab.com
Tue May 7 16:42:45 CEST 2019
On 07/05/2019 16:11, Bernhard Lindner wrote:
>> 1) the the change to qsizetype as an index type has not
>> happened yet, anyhow. It's still a huge question if it's doable in the
>> first place.
> It is still discussed? I thought it is pretty high at the priority list anyway.
No such patch has landed, and the discussion on the mailing list
stopped. I'm just guessing it's going to be one of the major points of
debate during the container changes expected for Qt 6. It needs some
serious experiment on some big code base.
Disclaimer: I'm against this change, presented like that, on source
compatibility reasons. If we can somehow get 100% SC, then I am totally
in favour of it.
> I mean, if you don't do that in 2020 (Qt6), when will you do it? You can't do it in a
> minor release, can you?
> x64 is standard in many applications and memory sizes are growing. I have seen to many
> platforms/frameworks die an early death because developers where afraid to enforce
> fundamental architectural fixes/improvements (including evolving language)... until it was
> too late.
The hard answer would be: never.
If you need a 64-bit ready byte
array/vector/map/hash/list/deque/stack/..., the Standard Library has
been providing them for a very long time now. Qt should make the
transition towards them easier. The reason why I'm still in favour of
the change above is getting a 64-bit QString, whose equivalent simply
does not exist in the Standard Library yet.
(Honorable mention: QStringView is 64-bit ready.)
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...
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
More information about the Interest