[Qt5-feedback] Real 64 Bit support ?

[André Pönitz]

On Tuesday 17 May 2011 11:17:48 ext Thiago Macieira wrote:
> On Tuesday, 17 de May de 2011 10:26:39 Andre Somers wrote:
> > > That said, I'd much prefer ssize_t to the current int.  The 2GB limit on
> > > 64bit systems would disappear, without impacting 32bit systems.
> > 
> > Then we are back with data exchange issues, are we not? How would a 32 bit
> > Qt application deal with a data file that contains a list of 2^32 + x
> > elements? Or that requires an address space larger than 2^32?
> 
> Well, you have to remember to properly cast the size type to a fixed width 
> (i.e., not ssize_t). The wire format must be the same, so we must choose the 
> 64-bit type.
> 
> That means writing code like this:
> 	stream << qint64(container.size());
> 	/* stream the elements */
> and
> 	qint64 size;
> 	stream >> size;
> 	container.reserve(ssize_t(size));
> 	/* read the elements */
> 
> Of course you cannot load more than 2^32 items into a container on 32-bit, so 
> your question is not relevant.

Sorry to repeat myself. The question is relevant.

Right now we can exchange a QVector between _any_ platform, with "natural"
syntax for reading and writing, without _any_ casting. One does not have to
care at all for the platform. It just works.

Changing int to ssize_t means (a) source incompatibility, and (b) there are now 
some QVectors that can be written on a 64 bit machine without error, but not
read back on a 32 bit machine at all.

[Changing int to unsigned also means source incompatibility (see the indexOf
"problem").]

[Changing int to q[u]int64 everywhere _also_ means source incompatibility
and a performance hit on architecture without "native" 64 bit type.]

So all three possibility lead to source incompatibility, warnings at best, silent
breakages in other cases. _I_ certainly don't want that. Doing that just 
"because we can" is insane.

I thought we already settled on "keep sources compatible unless it _really_
hurts". We can discuss whether keeping the inability to have more then 
2 billion items / 2 GB counts as "really hurts". I still claim it doesn't, as any 
real application needing containers that big will have left behind the implicit 
shared Qt containers _a long time_ before it hit the size limit.

So this is a discussion about real loss in the cross-platform promise vs a 
perceived but not-really-existing gain. 

I could agree with adding _another_ QVector64 class template or something 
similar as already suggested by others in this thread, but then, people really
who really need that could just use std::vector.

Andre'