[Development] qsizetype

[Edward Welbourne]

Volker Hilsheimer (5 September 2022 17:31) wrote:
>> We have virtual functions that take int and could potentially be fed
>> by the return value of container.size() (or generally need to be able
>> to handle values >2G), so should take a qsizetype (say,
>> QAbstractItemModel::insertRows, overridden by QSqlTableModel). I
>> don’t see how we can change those until Qt 7.

We can, however, get ahead of the game with the Qt 7 version already
sketched out and tested in advance, within #if-ery.  It may bitrot a bit
between now and Qt 7, but getting it substantially ready now should make
the 7.0 preparations less frenetic than what I was doing two years ago,
upon discovering how many ### Qt 6 comments were going unattended.

>> So we will have to live with some inconsistency.

Indeed.

>> For the other modules, esp those related to user interface
>> development, the chance that an int-API is called with a value above
>> 2G seems very low, even if they are operating internally on Qt
>> containers. I might be missing some real world examples though where
>> e.g. QGraphicsScene or a QTextDocument needs to operate on >2G items.

While I mostly agree, I do feel obliged to point out that there are
surprises out there.  It's now about a quarter century since I had to
rework a GIS system's datastore to cope with vector maps with more than
2 Gi of data describing the entities in them, because we had customers
whose datasets were that big.  (As this had to work on systems with
32-bit fpos_t, this involved a virtual file system.  But we had one of
those anyway, so I just had to teach it to be 64-bit safe and split each
logical file up into <= 2 GiB physical files.)  So there have been folk out
there with vast datasets for (at least) a quarter century.  I suspect
most such folk are still in the "specialised" category, so don't really
expect them to be using Qt to manage their vast data-sets, but I do
expect there shall be ever more use-cases where folk gently find the
sizes of their data-sets growing and will be "disappointed" if they hit
a 2 Gi size limit in the software they're using.

In most cases such datasets can and should be handled progressively, but
letting the author of a prototype do it the dumb way - by loading
the whole dataset in one go - will mean they can do the prototype in Qt,
which makes them more likely to still be using Qt when they do the
production version (and optimize away the insanely huge loads).

Marc Mutz (5 September 2022 19:15) wrote:
> Experience shows that we'll have many, many, many things to consider
> come Qt 7. And as Qt 6 has shown, such trivialities will be left by
> the wayside.

See above; indeed, two years ago, I discovered many things, some of them
by no means trivial, that had been punted to the major version and
forgotten about.  That was in addition to all the things I knew about
that needed to happen at the major version change.

This can, however, be at least party addressed by judicious improvements
to process: we could, for example, require every ### Qt 7 comment to
mention a Jira ticket describing the work that needs to be done for Qt
7, of which it's a part, marked suitably in Jira (Fix version 7.0,
perhaps a tag), so that we can search effectively for these tickets when
the time comes.

> So, playing the devil's advocate here: if this work is too much for Qt
> 6.x, what makes us think we'll get it done in the frenzy leading up to
> Qt 7.0?

We can be better prepared than we were for Qt 6.  We can do quite a lot
of preparation now to reduce that frenzy: simple mindless #if-ery on
QT_VERSION can do some of that, the QT[67]_ONLY macros some more.

> We have the tools (QT_REMOVED_SINCE + Ivan's work on
> -disable-deprecated-until) to have a user-configurable, rolling BC
> window now. We should use these tools to avoid accumulating too much
> technical debt until 7.0. From a C++ POV, we now only need major
> versions to break polymorphic inheritance (incl., but not limited to,
> virtuals), and signals and slots (the latter because of conflicting
> SC-solutions for new-style and old-style connects).

All of which also helps us reduce the amount of work we're forced to
leave pending until Qt 7; we can do it now and they'll happen naturally,
without any work during the mad frenzy.  We can then clean up after that
frenzy subsides, rearranging the code to take version >= 7 for granted,
starting after feature-freeze.

> That said, no actual user-visible size-mismatch bug has yet required
> the change of public interfaces.

This is good to hear; but see above.  I do think it's only a matter of
time before some class of client code does run into a need to manage
data-sets we would presently consider insanely huge; and we'll probably
be surprised by which application domain ends up needing it first.

For that matter, the further we progress towards 64-bit usage, the more
"specialized" categories of software there shall be, that presently have
to use custom software to handle their vast datasets, for which Qt shall
be a viable choice - enabling them to vastly reduce the amount of custom
code they need to maintain.  There is a growth opportunity here.

[snip]

> 1. Fix all int/uint in the implementation

Just remember that the replacement isn't always qsizetype.  At least
when the int is a number of milliseconds, please use qint64 for
consistency with our timers and date-time code.  I can imagine there are
other cases - indeed, wherever the int is not an index or size, I
conjecture that qint64 is a better choice than qsizetype.

	Eddy.