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

[Thiago Macieira]

On Friday, 2 November 2018 06:50:50 PDT Jedrzej Nowacki wrote:
> On Friday, November 2, 2018 4:42:52 AM CET Thiago Macieira wrote:
> 
> > We have a lot of API that, for Qt 6, we've already decided to extend to
> > 64-bit on 64-bit platforms, but keep as decently-sized 32-bit on 32-bit
> > ones.
> 
> Smells like qreal, with all problems that it causes... We could reconsider 
> costs of using 64bit everywhere, it would streamline debugging of edge
> cases. 

[Intel hat on]
I don't mind this. All Intel processors are 64-bit, all Linux workloads are 
64-bit.

[Qt maintainer hat on]
Sorry, that would mean 32-bit builds use a larger-than-a-register type which 
means extra carry operations and slower multiplications. That's probably not a 
good idea.

> If I have to I would also pick option 4, but:
> 1. qsizetype can _not_ be a built in metatype in Qt5 (at best an alias).

It's not going to be. It's a typedef to either int or long long, depending on 
your pointer's size.

> 2.  qsizetype needs to have QDataStream operators so it doesn't fallback to
> a  platform dependent size

Since it's a typedef, that can't happen. But you've got a point: we need to 
serialise in explicit 64-bit widths.

> 3. QDataStream stream autotests of class that uses the type would need to be
>  extended.
> 4. I bet there is more, issues to solve, caused by pointer arithmetic ...

No doubt. That's why I wanted to start now.

> I would not try to trick qdoc to not see it. The consequences of size
> changing  "randomly" are far too important, to be hidden.

So you want users to know now, in Qt 5, that this particular type in the API 
will become qsizetype in Qt 6?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center