[Development] QtCS2019 Notes: QtCore

[André Pönitz]

On Sat, Nov 23, 2019 at 11:26:02PM +0100, Thiago Macieira wrote:
> On Saturday, 23 November 2019 13:55:52 CET André Pönitz wrote:
> > Also, replacing size() by count() would be easy to do in e.g. Creator
> > (effectively a single global renaming of size() to count() and discarding
> > the changes to Qt itself).
> > 
> > Wrapping int() around requires more manual work.
> 
> I understand, but I think this is the type of change that will eventually 
> become a problem down the road. We think it can help with porting, but it may 
> later introduce subtle bugs by truncating sizes.

The cases that a user application _needs_ >2GB elements in a _Q_Container,
are extremely rare, for two reasons:

First: Such cases rare are in general. I think the only case in Qt Creator code
where 64bit indices into anything were needed, is the binary editor, and
there's effectively file positions.

Second: The only benefit of QContainer is ::fromRawData, in all other cases
the costs of implicit sharing are rather a problem then a benefit. So the
typical solution would be to use std::vector etc in that case anyway.

Practically, those occurances are singular arrangements within an application
that then also get special attendence by the developers. This is less of
a problem than mass-replacements.


Regarding the risk of "introduce subtle bugs by truncating sizes": That risk
_is_ there in general for some of the proposed porting strategies, but not for
the case of using a 32bit count(): We can assume that an existing application
using QContainers is fine with 32bit, otherwise it wouldn't work right now.
So continuing using 32bit interfaces does not introduce bugs. Immediate
truncation on the user code sode is also riskless, just ugly.

Andre'