[Qt5-feedback] Real 64 Bit support ?

[BRM]

----- Original Message ----

> From: André Pönitz <andre.poenitz at nokia.com>
> On Thursday 12 May 2011 13:58:48 ext Keith Gardner wrote:
> > I would also  like to see this. On top of a 64-bit build, I would like to 
see
> > the  container classes (QVector, QList, etc...) have a qint64 to index the
> >  values instead of a qint32.
> 
> qint64 is expensive on (at least some) 32 bit  machines.
> 
> Having _different_ sizes (32/64 bit) depending on architecture  spoils 
> cross-platform data exchange using e.g. QDataStream. So that's  even
> less of an option.

I'd argue that QDataStream should be more protocol oriented then as that can be 
defined in the protocol used to communicate the data.
But that's a different issue altogether.

> Having 31 bit for sizes is definitely "good  enough" for all kinds of 
> "mainstream" use cases.
> 
> For exceptional  casew like "really needing more then 2 billion items in a
> container" (and I  had that myself...) QList/QVector are typically not suited
> for other reasons  (implicit sharing e.g).
> 
> So having qint64 indices will practically _hurt_  a lot of people and I would
> not expect it to help anyone. So why change it  then?

So what then happens when we _do_ need it? Are we going to be laden to 
applications that do not need it?
And with the growth of RAM and data stores - like Nepomuk/Strigi/etc that day is 
going to come sooner than you may realize, so why not start it into the plan?

Iterators can get your around it but only so far - since you can't easily skip 
from index 0 to index 50,000,000 with an iterator with consistent performance 
across all objects types.
 
> > > For what it worths, I totally second this: true 64bits  support is a real
> > > need, having to manage really huge datasets -  here "huge" can mean
> > > far more than 4GB.
> 
> On a quick glance, I  think the limit can be raised to only affect the item 
> count, not the size by  changing two lines in QVectorData::malloc and grow.
> 
> For 'double' data the  size limit would be 16 GB then, and I am pretty sure
> you would have switched  to non-shared container long before that.
> 
> And to pre-empt the "int vs  uint" debate. I don't have a strong opinion here.
> On the "pro" side we have  less typing, a safe way for "interating downwards",
> the latter with the  potential to safe a register when looping, and a way to 
> specify an "invalid"  index (-1 is used for that in the Qt API commonly). 
> Also changing it would  _silently_ break code that relies on "index < 0"
> conditions.
> 
> On the  "contra" side, it reduces "address space" by a factor of two, and 
> it's  different from what the Standard Library does. 
> 
> So I am leaning to the  "leave-as-is" side here too, but not as strongly
> as in the 32-vs-64 bit  case.
> 

I can see the "leave-as-is" for now, though I still do stress the above 
situation, but it's probably not going to be something that can be put off 
beyond Qt6 - e.g. timing-wise Qt6 is probably the latest this change will have 
to be made.
So it is going to have to be done.

At the very least, we should probably start advising people that a change will 
happen - whether it's qint32->quint32, or qint32->qint64 or whatever, and what 
people should start preparing to do in changes to their logic to support the 
change.
For instance, advising against using "index < 0" as a test for an invalid index, 
and pushing people use container.isEmpty() to test if an index is valid, perhaps 
even add a 'hasIndex()' function to all classes that it could be an issue with 
and advising to use that.

My point being - there are multiple ways to tackle this issue, and it's going to 
be one that will eventually rear its ugly head; so why not at least start the 
momentum towards the change so that when it does happen it can happen smoothly. 
Qt5 should be a good place to start building that momentum.

$0.02

Ben