[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