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' _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
