[Qt5-feedback] Real 64 Bit support ?

[André Pönitz]

On Thursday 12 May 2011 15:31:42 ext Andre Somers wrote:
> Op Do, 12 mei, 2011 2:53 pm, schreef Yves Bailly:
> > Le 12/05/2011 14:42, André Pönitz a écrit :
> >> 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.
> >
> > True.
> >
> >> 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.
> >
> > Data exchange implies serializing things in a very controlled way, isn't
> > it?
> > I avoid sending a mere "int" through a QDataStream, I always cast it to a
> > known-size type, e.g. int32_t or int64_t (depending on the needs). I would
> > treat "size_t" just the same way, so no data exchange problem.
> 
> Errr... How do you see that happening? What happens if the data in that
> stream as 2^34 elements, and you try to read it in on a 32 bits platform?
> 
> But I _can_ see that there may be cases where you'd like to have more
> space. Dare I suggest that perhaps the Qt container classes should be
> templated with respect to their index type? Default would still be
> Q_INT32, but you could pass in Q_INT64 if needed?
> 
> QList<MyType> myNormalList;
> QList<MyType, Q_INT64> myHugeList;
> 
> or something like that?

Possible.

But: Have you ever _personally_ needed that, for a Q* container? 

I already admitted that I already used larger data sets, so I am not 
disputing that these cases exist. I just don't believe they are common
enough to justify the transition pain and feature loss otherwise.

From my (personal, but now sure how personal) point of view, keeping 
source compatible with Qt 4 as much as _painlessly_ possible is a 
worthy goal. I am not against breaking it if there is a _real_ gain, but 
in this case here I simply can't see any.

[And yes, the proposed change breaks sources, albeit in a minor way.
Introducing the second template argument would trigger a change to 
three lines in the Creator source code (forward declarations of QList)]

Andre'