[Qt5-feedback] Real 64 Bit support ?

[André Pönitz]

On Tuesday 17 May 2011 13:05:01 ext BRM wrote:
> > Right now we can exchange a  QVector between _any_ platform, with "natural"
> > syntax for reading and  writing, without _any_ casting. One does not have to
> > care at all for the  platform. It just works.
> > 
> > Changing int to ssize_t means (a) source  incompatibility, and (b) there are 
> >now 
> >
> > some QVectors that can be written on  a 64 bit machine without error, but not
> > read back on a 32 bit machine at  all.
> > 
> > [Changing int to unsigned also means source incompatibility (see the  indexOf
> > "problem").]
> 
> This is solvable even without using C++ Exceptions. However, it would break 
> binary compatibility so is not an option for Qt5.

No. Breaking binary compatibility is not a problem for Qt4->Qt5. The plan is 
"only" to try to stay source compatible, within reason, and it would be even 
ok break that if it makes sense.

> The binary compatibility requirement is perhaps the only reason not to go to 
> unsigned int for Qt5.

There have been others mentioned in the thread. It e.g. breaks currently working
code like

   for (QVector<int>::size_type i = 10; --i >= 0; )
        ;

In some configurations (such as gcc without -Wall) even silently.

> [..]
> I believe the requirement  was that source incompatibility was acceptable while 
> _binary_ incompatibility was not; no qualifications given per source 
> compatibility. Or was I mistaken on Nokia's intent there? (Thiago?)

You are mistaken.

> > So this is a discussion about real loss in the cross-platform  promise vs a 
> > perceived but not-really-existing gain. 
> 
> Not necessarily true. Applications use 64-bit indexing for numerous things, and 
> may need 64-bit indexed containers too where it makes more sense to use the Qt 
> (or even std variant) container than to write their own.

You are mixing up two mostly independent issues. One is using 64 bit indices
and the other is using QVector. Using big data sets requiring 64 bit indices 
is fine. If you need it, use std::vector. Problem solved. Using QVector in that 
situation has never been a good idea, and the main reason for that is _not
the indexing_ but the performance impact of implicit sharing for simple 
write access.

Please name _one_ application that actually would prefer to use _QVector_ 
(or any other implicit shared container) over std::vector for 2 GB data sets.
One. Only one, and I'll rest my case.

Andre'