Re: [boost] [Booster] Or boost is useless for library developers

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Isidor Zeuner (boost_at_[hidden])
Date: 2010-05-16 21:36:37

> > those who are always caught in a "should we fix this
> > bug? it makes
> > applications break, but fixing it would break the ABI"
> > dilemma.
> 
> ABI compatibility should not prevent fixing bugs. This is important
> point. In fact libstdc++ manages its ABI for 6 years successfully,
> Qt does this very well too.
> 

These are very different cases. libstdc++ implements functionality
which has been standardized for a long time. Qt uses a lot more
indirection than boost does.

> However you need to be prepared. You generally need at least one
> d-pointer/opaque-pointer/pimpl. You need to separate implementation
> and definitions (it would also increase compilation time, and
> reduce code size).
> 

Honestly, if boost was changed to use these indirection techniques in
all places, I'd probably fork it or go for an alternative
solution. Indirection might solve the fragile interface problem and
reduce compilation times and code size, but it also effectively blocks
any compiler optimization which spans multiple methods that could be
inlined before. Consider boost::phoenix: as we have it now, without
indirection, I can write expressions using phoenix and count on a
decent compiler to optimize all the classes out, leaving me with
native code which often is no different than if I had coded the
expressions by hand. A pimpled boost::phoenix would result in lots of
indirect calls all the time, which would badly hurt performance.

As stated before, I would consider it useful to have a boost::abi
module which abstracts away the internals. This would probably use one
of the indirection techniques you mentioned. But I don't think
something like this should be scattered throughout the whole boost. I
would not want to have yet another lightweight layer which could fit
between boost and C++. I'd rather think of boost as a toolset
sitting right on the top of C++, which is not necessarily binary
stable, but can be used to build the hard bits of a binary stable
library.

BTW, I would rather compare boost not with Qt or libstdc++, but with
Linux kernel development. They also work at a very low level, and they
came to the conclusion that a fixed ABI would be to costly. I think a
fixed ABI is something that should only be considered on a higher
level.

> > I need updating strategies for large deployments of
> > binary
> > modules which are a bit more granular than "upgrade boost,
> > then
> > recompile everything".
> 
> Exactly, this one of very important issues that ABI stability would solve.
> 

It surely would. But I do not regard it as the best solution. A stable
ABI would just mean even larger deployments using the same ABI, just
waiting for the day where some design issue makes it unavoidable to
break the ABI. Then the problem is even bigger.

A better solution, at least in the boost case, would be to make a
volatile ABI more manageable.

Best regards,

Isidor