----- Original Message ---- > From: André Pönitz <[email protected]> > 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 _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
