[Interest] Qt container size()

[André Pönitz]

On Thu, Jan 29, 2015 at 02:32:13PM +0100, Felix morack wrote:
> Is there any reason for this? Why dont they use size_t like the STL and
> the rest of the world?
> 
> It's 2015, people will increasingly bump into this limitation - i just
> did.

If you have 2^31 items or more in a container you *need* to rate
performance over convenience and you don't care about portability of your
application between 32 and 64 bit systems. Qt containers generally
work the other way round.

Regarding convenience only, http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4165.pdf might be an interesting read.

Pick the right container for the task, don't base your decision on
class name prefix ("Q" or "std::"), and don't impose the special needs
of your use case on every one else's applications.

> I very much prefer QTL over STL for easier Qt integration, superior API
> and implicit sharing.

Implicit sharing is a performance killer. It makes user code prettier,
but optimizes a usage pattern ("needless" copies) that's avoidable, and
pessimizes usage patterins that are unavoidable (write access). You do
*not* want implicit sharing for containers with more that 2^31 items.

> But this is a bit of a bummer.
> 
> Any plans to fix this situation for Qt6?

I am afraid we'll see the same discussion from 5 to 6, but I hope the
outcome will be the same.

There's nothing to fix. At least not for the majority of containers.

Keeping them as-is was the right decision when going from Qt 4 to 5.
Porting from 4 to 5 would have been much harder if container size()
changed, keeping the same application code compilable with 4 and 5
would have been a nightmare.

I would be willing to make an exception for QVector (and only that),
this could, or even should, be a lightweight "fullsize" container.
The portability reason carry less weight in this case, as it's barely
used in the Qt API.

Andre'