[Development] Abandoning the container changes

Marc Mutz marc.mutz at kdab.com
Wed Jul 18 14:00:08 CEST 2012


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).

Thanks,
Marc

-- 
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