07.05.2019, 17:45, "Giuseppe D'Angelo via Interest" <interest@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. -- Regards, Konstantin _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
