[Development] Abandoning the container changes

Olivier Goffart olivier at woboq.com
Wed Jul 18 15:51:26 CEST 2012


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



More information about the Development mailing list