[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