[Qt5-feedback] Real 64 Bit support ?

Stephen Bryant steve at bawue.de
Tue May 17 12:38:53 CEST 2011


Hi André,

On 17/05/2011 10:26, Andre Somers wrote:
> I agree there, though there are things to considder. Like, what would you
> return from a method like QList::indexOf()?

Ummm..  std::out_of_range?

The question is, why are we using a size variable for error reporting?

I think STL's interface is cleaner in this regard.  Too bad it's not as
feature-rich as Qt.

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

One could theoretically return QList::size() or (size_t) -1.  Reducing
by one instead of halving the number of elements would be good, but I
think you're quite right that the behaviour change is not insignificant,
and probably too much to accept.

What seems to be missing is this QList method:

   iterator find( const T & value,
                  const_iterator from = constBegin() )
   // returns end() if not found

Maybe we could get that in Qt5!


>> 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?

I have to ask - how do you download a file >4GB on a 32bit system right
now?  That has more than 2^32 elements.  :-)

As others have mentioned, the wire format must be fixed.  I would also
hope that the sender checks whether the receiver can handle that much
data first!

Steve


More information about the Qt5-feedback mailing list