[Interest] Operator QMap<uint, uint>[] is casting to int?

Konstantin Tokarev annulen at yandex.ru
Tue May 7 16:49:03 CEST 2019

07.05.2019, 17:45, "Giuseppe D'Angelo via Interest" <interest at qt-project.org>:
> 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.)

You were asking when static_casts between int and size_t are needed.
Interfacing Qt-based code with Standard Library types is one of such cases.


More information about the Interest mailing list