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

[Edward Welbourne]

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

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.

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.

	Eddy.