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' _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
