[Development] Abandoning the container changes

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Tue Jul 17 23:59:06 CEST 2012


On Tue, Jul 17, 2012 at 05:19:23PM +0200, Oswald Buddenhagen wrote:
> On Mon, Jul 16, 2012 at 02:52:32PM -0700, ext Thiago Macieira wrote:
> > On segunda-feira, 16 de julho de 2012 21.34.10, André Pönitz
> > wrote:
> > > On Thu, Jul 05, 2012 at 09:04:39AM +0300, Thiago Macieira
> > > wrote:
> > > > I think that, despite the potential benefits of the changes,
> > > > we should not apply them at this time. There are far too many
> > > > chances for breakage and it's a blatant disrespect for the
> > > > feature freeze.
> > > 
> > > I assume this is meant as a verdict, not as (possibly
> > > temporary) state of thinking.
> > 
> > Correct. The changes are the right thing to do, just not now.
> > We'll have to live with the current containers and their overhead
> > until Qt 6.
> > 
> > That includes the fact that QList<QVariant> is extremely
> > inefficient.
>
> this is absurd.

Incidentally, I agree. [Even if I lack the skill to express myself
so clearly at times ;-}]

> we said A, now we need to say B. or "unsay" A, which i don't think
> anyone wants.
> 
> i for one don't believe in qt6 anytime soon. it's the do-never release
> qt5 was for years. 

The suggested "4 years" are 3 1/2 years too much anyway.

That's 3 1/2 years more of forcing people to re-invent the wheel when
it comes to performance-sensitive components in a Qt environment, and
it's 3 1/2 years on top of the past half decade or so where Qt containers
fail to deliver on one of the original reasons to have them at all
(portability, convenience of use, _and_ performance).

We do have the chance to fix it _now_, and we have a fairly decent
idea of how the fix looks like. The whole change is essentially
source compatible, i.e. has a low probability of breaking other
components, and it is very well covered by autotests. The chances
to be ready before the rest (Webkit Windows? Mac?) is ready for
a 5.0 release are good.

To get back on the constructive side I propose to do any of the
following, in decreasing order of desirability: 

(A) Have the QString/QByteArray related bits in 5.0.

(B) Have everything in 5.0.

(C) Don't do anything for 5.0, but aim for a 6.0 instead for a 5.1
next.

(D) Don't do anything for 5.0, but allow 5.1 to be source compatiple
but binary incompatible.

(E) Don't do anything for 5.0, and provide a compile-time switch
for 5.1 to select between "current" and "patched" versions, default
to "current". [This is probably the most expensive solution, but
the one that fits best to "the rules"]

Andre'



More information about the Development mailing list