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-15 08:45:06

Hello,

> 
> Let's assume I want to use `boost::shared_ptr` as one of the most important
> parts of boost in my library interface...
> 
> Impossible. why?
> 
> Even, for such a small part of boost with stable (even tr1) definitions
> it is impossible to promise that it would not be broken between releases.
> 
> Why boost::details::sp_counted_base may be changed because in next
> version atomic counter was implemented using assembly rather then
> pthread's mutex... which affects the layout of
> boost::details::sp_counted_base and thus breaks compatibility.
> 

This is solely about binary interface compatibility, right?

I dare to say that this is a tradeoff that is accepted by adopting the
template-based design. Boost calls itself a template library, after
all. Inside a library or application, this is exactly what I ask for:
C++ allows me to trade stable binary interfaces for more in-depth
optimization possibilities, and I see boost as a valuable community
effort which explores these possibilities.

As soon as library boundaries are reached and one wants to care about
binary compatibility, boost might just not be the right tool for the
job. But why not using what boost has to offer inside the library, and
approach the library ABI problem separately?

What I find more problematic is the mix of header-only and compiled
libraries boost has: If I would use a purely header-only template
library for writing libraries and built the interfaces independently
from the changing parts of the template library, I could decide for
each library separately if I want to compile it against an upgraded
template library or rather keep an old version. As soon as I do this
with boost and start to use libraries with compiled parts, I have to
keep them all in sync with the installed compiled libraries.

But apart from this issue, I'd say boost is very good at what it
does. And maybe it's even possible to approach the ABI problem in
a dedicated library. For example a boost::abi which strips out all the
juicy parts and is able to expose data in some kind of an abstract
virtual method based interface. This comes with some overhead, but
then again it's only at the library interface, while some
libraries have this overhead in all possible places. Or maybe
boost::corba...

As far as I understand your effort, you are more or less taking boost
and try to keep the binary layout stable. Personally, I'd fear to
get stuck on less than optimal design decisions that the official
boost can simply abandon because it is not bound to binary
compatibility. So I feel more comfortable with tackling the interface
problem separately.

> 
> - It uses CMake instead of Boost.Build.

Let me also do some advertising :)

You might be interested in my recent effort to resurrect boost-cmake:
[1]

> 
> Think of GTKmm, think of Qt, think of kdelib - that no-one can use it
> just because they promise backward compatibility.
> 

Well, to achieve this I see for example Qt reinventing about every bit
of STL. This is a way to ensure binary compatibility, but is it the
right way to go?

Best regards,

Isidor

[1] http://permalink.gmane.org/gmane.comp.lib.boost.cmake/833