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

Thiago Macieira thiago.macieira at intel.com
Tue Dec 4 23:52:50 CET 2018


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. 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






More information about the Development mailing list