[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KAutoPointer: a new autoptr class for QPointer
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2009-07-11 10:23:20
Message-ID: 200907111123.26669 () erwin ! ingo-kloecker ! de
[Download RAW message or body]


On Saturday 11 July 2009, Harri Porten wrote:
> On Fri, 10 Jul 2009, Thiago Macieira wrote:
> > Harri Porten wrote:
> >> On Fri, 10 Jul 2009, Thiago Macieira wrote:
> >>>> BTW, Qt has broken source compatibility even for the rather
> >>>> trivial container classes three times already making it
> >>>> impossible (much to my regret) to argue in favor of Qt's
> >>>> containers in discussions about using the STL containers
> >>>> instead.
> >>>
> >>> I don't recall of any important breakage in Qt 4. We're very
> >>> careful about that.
> >>
> >> I guess Ingo meant the three major breakages between 1/2, 3 and 4.
> >> As much as I'd like to use Qt container classes everywhere
> >> (including non-GUI) code the track record is rather weak compared
> >> to STL containers and other libraries. GUIs come and go - code
> >> under the hood often has to live much longer :)
> >
> > Huh?
> >
> > GCC 2.7, GCC 2.96 (unofficial release), GCC 3.0, GCC 3.2, GCC 3.4.
> > That's 5 separate API/ABI breakages that I can remember. Though I
> > also thought that 2.95 had a breakage, I think it actually didn't.

You are comparing apples (BIC) with oranges (SIC).


> Ingo talked about *source* code incompatibilities. Binary
> compatibility is nice but only secondary in comparison. Recompiling
> an application against a new ABI (possibly fixing some accidental
> regressions) is ridiculously easy compared to porting it to a new
> source API.

Exactly.


Regards,
Ingo

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]