[Development] Another integer typedef OR how to prepare for 64-bit in Qt 5

[Konstantin Tokarev]

05.12.2018, 02:03, "Thiago Macieira" <thiago.macieira at intel.com>:
> On Tuesday, 4 December 2018 12:29:32 PST Bernhard Lindner wrote:
>>  > > Then let me rephrase my opionen: What every you plan to change regarding
>>  > > size types in Qt6... do it the standard (C++20?) way.
>>  >
>>  > We're doing it the way the committee says it should have done in the first
>>  > place, not the way it has done: signed.
>>
>>  If this plays well with the language and standard library features I am ok
>>  with it. It doesn't remove all the additional effort I mentioned but it
>>  will prevent the unnecessary interfacing/casting. As soon as user code is
>>  be rebased to ssize/C++20 and qsizetype everything is consistent which is
>>  the most important thing. And I suppose other libraries will follow the
>>  coming standard soon.
>
> The point is that you don't need size_t.

Unless you do need it, when interfacing with code which uses size_t. For example,
WebKit code base uses size_t as size type across the board, which causes lots of
conversions to signed in code which glues platform-independent code with Qt APIs.

> And with the Qt API, you do need
> negative indices, since we have things like
>         indexOf(T t, qsizetype from = 0)
> where a negative index means to search from the end.
>
> Restricting the discussion to modern, Von Neumann / modified Harvard systems
> where sizeof(ptrdiff_t) == sizeof(void*), the only way you can have an in-
> memory container with more than PTRDIFF_MAX items is if the size of those
> items is 1. If it were 2, then PTRDIFF_MAX items would mean SIZE_MAX-1 memory
> used, which is impossible. It also rules out any container with an overhead of
> 1 byte or more per element, such as linked lists.
>
> You can't have a memory block that is larger than PTRDIFF_MAX bytes either,
> otherwise end - begin < 0 and that's nonsense. That rules out
> std::vector<char> too.
>
> So you need a container of char/byte that has an overhead of less than one
> byte per element, but does use more than one memory block. That's
> std::deque<char>. How often do you use that?
>
> So my conclusion is that if you need to operate on something that even comes
> close to PTRDIFF_MAX elements, you need to look into an out-of-memory
> representation (think database).
>
>>  BTW Are there plans/roadmaps regarding C++20 support?
>
> No different than C++17. I already have some experimental code using <compare>
> and the spaceship operator, which showed that the Clang/libc++ implementation
> is incomplete. See qcborvalue.h.
>
> Someone should add the "c++2a" config to qmake too.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development at lists.qt-project.org
> https://lists.qt-project.org/listinfo/development

-- 
Regards,
Konstantin