05.12.2018, 02:03, "Thiago Macieira" <[email protected]>: > 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 > [email protected] > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
