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

[Jedrzej Nowacki]

Dnia piątek, 2 listopada 2018 16:02:55 CET Thiago Macieira pisze:
> 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.
I know. What I do not know is if that really matters for users, especially as 
we can use 64-bit values in API but 32-bit  values in the implementation. Nah, 
I have to admit, not the greatest 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.
Good

> > 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.
Yes that was the thing I tried to express :-)

> > 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?
Yes, or to turn it around, why not? It sounds like an information, which 
doesn't obscure generated documentation and which would implicitly document 
porting Qt5->Qt6. On the other hand it is a really minor detail, both 
approaches are valid :-).

Cheers, 
  Jędrek