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. -- Olivier Woboq - Qt services and support - http://woboq.com _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development