----- Original Message ---- > From: Andre Somers <[email protected]> > Op Di, 17 mei, 2011 10:11 am, schreef Stephen Bryant: > > On 17/05/2011 09:13, Thiago Macieira wrote: > >> Indeed. That's also the reason why we use ints: if they are used for > >> everything, there are no warnings about mixing signedness or losing > >> precision > >> due to casting to a smaller type. > > > > Only until you have to pass the size of something to/from some other > > interface. > > > > All you're doing is moving the hurdle! I have to write extra code to do > > bounds checking because of the signed integer, and because of the loss > > of precision. > > > > It would be better to use unsigned values for sizes of things like > > everything else does. No warnings then either. > I agree there, though there are things to considder. Like, what would you > return from a method like QList::indexOf()? Currently, you get a -1 if > your search did not return any results. But if you change this to an > unsigned integer, what would you return? Perhaps reserve its maximum value > to be the invalid one (and thus making the address space 1 shorter, > instead of dividing it by two). In any case, this would require lots of > code changes in code currently out there. The goal of Qt5 was that it > would stay largely code compatible...
While I fully would like the unsigned int type used myself; with Qt5's main goal of binary compatibility, etc I can fully see that switching to ssize_t is best for now, but it should be planned on how to move it to unsigned for the next binary incompatible release - e.g. Qt6 or whatever that is. > > 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? > Except you already have that problem, only it extends to 64-bit builds too since the type is specific to 32-bit. Comparatively by switching to ssize_t, you could (at least theoretically) switch the definition of ssize_t on a 32-bit system to something larger (e.g. a 64-bit or 128-bit number) to get around it there too; thus if someone on a 32-bit system needed something that way they could simply recompile it as such and have the issue resolved - or even a switch could be added to Qt's build system to do so. The point is to move in a direction that removes the already existing limit. Ben _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
