[Qt5-feedback] Real 64 Bit support ?

[BRM]

----- Original Message ----

> From: Andre Somers <andre at familiesomers.nl>
> 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