[Development] Abandoning the container changes

Marc Mutz marc.mutz at kdab.com
Thu Jul 19 14:19:36 CEST 2012


On Wednesday July 18 2012, Olivier Goffart wrote:
> On Wednesday 18 July 2012 14:00:08 Marc Mutz wrote:
> > On Wednesday July 18 2012, Oswald Buddenhagen wrote:
> > > On Wed, Jul 18, 2012 at 12:25:37PM +0200, ext Marc Mutz wrote:
> > > > We don't even need to break binary compatibility. We could use inline
> > > > namespaces to let new code see the new containers while old code uses
> > > > the
> > > > old ones.
> > >
> > > and how exactly is this supposed to work?
> > > we are not talking about changing some private implementation details,
> > > but the publicly visible data structures which are fundamental parts of
> > > our api+abi. even if it's somehow possible to have different classes
> > > use different container implementations, the conversion overhead would
> > > be ridiculous.
> >
> > That's a question of how the new classes are designed. I don't see an
> > a-priori reason why, say, a v50::QVector couldn't share data with a
> > v51::QVector, esp. considering the flexibility that was already present
> > in Thiago's branch. There will be a conversion penalty of some form, but
> > only for applications that continue to use the old version (because Qt
> > will internally use the newest, of course). There will also be a
> > maintenance penalty, but we already pay it in the form of BC guarantees.
> > If we used inline namespaces, we would trade one form of maintenance
> > burden (keeping BC) for another (maintaining inline namespaces).
> >
> > The question is just: which one is more work? And frankly, no-one knows,
> > because there's no experience with inline namespaces (even though GCC
> > uses something similar for the debug STL containers for a long time).
>
> We discussed namespaces long time ago already, and decided not to put Qt in
> a namespace.
> The reason is that it breaks source compatibility by breaking all the
> forward declarations.

Even with inline namespaces? Then they would have failed to achieve their goal 
to hide the fact that the type is in an inline namespace.

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions



More information about the Development mailing list