[Qt5-feedback] Real 64 Bit support ?

[BRM]

----- Original Message ----

> From: André Pönitz <andre.poenitz at nokia.com>
> 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").]

This is solvable even without using C++ Exceptions. However, it would break 
binary compatibility so is not an option for Qt5.
The binary compatibility requirement is perhaps the only reason not to go to 
unsigned int for Qt5.

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

I believe the requirement  was that source incompatibility was acceptable while 
_binary_ incompatibility was not; no qualifications given per source 
compatibility.
Or was I mistaken on Nokia's intent there? (Thiago?)

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

Not necessarily true. Applications use 64-bit indexing for numerous things, and 
may need 64-bit indexed containers too where it makes more sense to use the Qt 
(or even std variant) container than to write their own.
So it's not necessarily a perceived benefit as a real benefit when moving to 
truly supporting 64-bit platforms.

Now the issue you raise, however, seems to be more of a protocol issue, and 
possibly in your case a file format issue. Those things are things that need to 
handled separately.
For example, you don't just start writing data to a file willy-nilly. You record 
the version of the file format - even if it to note that Qt 4.5.1 vs 4.6.2 vs 
4.7.1 vs 5.0.0 was used to write the file. I would expect that a file written 
with Qt 4 as you note with QDataStream should be readable by a program utilizing 
Qt5; I would not necessarily expect the inverse with that Qt5 program 
necessarily implementing a run-time configuration option to do so. Similarly I 
would expect that the Qt5 32-bit version would denote itself as being such in 
the file format and the Qt 64-bit version to do likewise so that can 
read-or-error appropriately.

Ben