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

[André Pönitz]

On Fri, Nov 02, 2018 at 02:36:26PM +0000, Edward Welbourne wrote:
> On Thu, Nov 01, 2018 at 08:42:52PM -0700, Thiago Macieira wrote:
> >>>> What do we do?
> >>>>
> >>>> Option 1: do nothing, wait for Qt 6 and do the change then
> >>>> Option 2: insert #if in our API, starting now
> >>>> Option 3: use #if per class, starting now
> >>>> Option 4: create a central #if and use this new type, starting now
> 
> On 2 Nov 2018, at 09:02, André Pönitz <apoenitz at t-online.de> wrote:
> >>> Option 5: Leave as-is, also in Qt 6.
> >>>
> >>> Known and bearable effort to handle the recurring 'why do you use
> >>> int?' threads.
> >>>
> >>> No effort for existing users, which otherwise will face lots
> >>> of size mismatch warnings in their code.
> 
> On Fri, Nov 02, 2018 at 08:52:07AM +0000, Lars Knoll wrote:
> >> And the drawback, that people can’t use large data sets with our containers.
> 
> André Pönitz (2 November 2018 10:26)
> > For large data sets the Qt containers usually aren't a good choice
> > anyway, as the trade-off of the implicit sharing is often not worth
> > it in that case.
> 
> On the other hand, not all users shall care: time to develop and ship
> the product may be more important to them than optimality of the code.

Correct. But in this context most of the QList-should-be-replaced-by
-something-else arguments are void anyway.

Also, the "don't touch" option is exactly that: People should not have to
worry about their existing code or potential regressions.

> In any case, datasets get bigger over time, and what was once though of
> as prohibitively large eventually becomes normal-sized.

Also correct. And sometimes this needs a different container or a new
algorithm. But then this happens in response to an actual need and
the resulting change can be expected to be tested reasonably. That's
different from an s///g shotgun that can hit "accidentally working" areas.

> Twenty years ago, I was implementing a virtual file-system in a GIS to
> let us deal with files > 2GB on systems where fseek() and ftell()
> couldn't handle that (because long was 32-bit) with real files.  Those
> files held datasets that represented a mapping agency's knowledge of the
> world, so were considered huge at the time.  Nowadays, similarly huge
> files are increasingly commonplace; and lots of code glibly assumes it
> can just open a file, grab all its contents into a buffer, work on it
> and emit the results to wherever it's going, without worrying about the
> file being "too big".  If the system's got the memory to allocate a 5 GB
> QByteArray without problems, there's going to be folks who do just that
> and who aren't going to be amused if our APIs (like fseek and ftell back
> in the '80s, before fpos_t was invented; or well into the '90s when O/S
> vendors were still slow to recognise that fpos_t needed to be 64-bit so
> that f[gs]etpos can take over) break that easy-to-code (though
> resource-squandering) pattern.  Which, at present, they do.

People will even expect to put a QByteArray into a QDataStream on one
machine and get it back on a second. Even if the first was some 32bit
embedded device and the second their 64bit desktop. Or the other way
round. People's expectations are sometimes strange and cannot always
be met.
 
> So I'm definitely in favour of ending the use of int in Qt's APIs, at
> least for offsets into (potentially huge) datasets; and Thiago's option
> 4 looks pretty reasonable to me.

I am aware of that.

Andre'