[Qt5-feedback] Real 64 Bit support ?

[André Pönitz]

On Thursday 12 May 2011 22:08:01 ext BRM wrote:
> ----- 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.

How would a protocol look like, that's used to put data into a file?

There's not much else that can be done than to use a certain format,
and if that's meant to read back by machines of a different architecture
the format needs to be acceptable by all target. 

QDataStream currently does precisely that. It works very well for that
purpose. No need to sacrifice it.

> > 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? 

Use std::vector. Or write a custom container. Qt cannot be expected to 
handle everybody's special use case out-of-the-box. You will always have 
to write some code yourself.

> 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?

We are not talking "databases" here. We are talking about general purpose,
easy-to-use containers.

> [...]
> 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.

I personally don't see the need of such a change at all, so from my side
there's nothing to prepare.

One thing that I _would_ like to change for Qt 5 is the implicit sharing for
QVector, for performance reasons. QVector is hardly ever used as return
type in the Qt API, and even in such cases compilers nowadays are pretty
aggressive at optimization (gcc e.g. applies RVO even at -O0). So the gain
of implicit sharing is close to zero. On the other hand, we pay for it in each
write access, making it a bad choice for large datasets.

[And to be clear, I said "QVector", not "QList", not "QString" etc.]

> 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.

The idiom  "for (int i = vec.size(); --i >= 0; )" is currently the one that 
produces the best cross-platform general-purpose looping code in the 
sense that it is as good as alternatives, and there are some cases 
(compiler/platform) where it is better. [The only exception I am aware
of are cases where gcc automatically uses SIMD instruction. That
(at least up to 4.5, haven't looked lately) only occurs for "++i" loops.]

So your suggestion to advise against using index < 0 basically means
deprecating the "best of breed".

Andre'