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.m...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
