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

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-05-15 09:23:17

> 
> This is solely about binary interface compatibility,
> right?
> 

Yes.

> 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.

Not exactly... Many if not most libraries consists of template part and
non-template part.

> <snip>
> 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. 

The problem that for C++ today is **THE** library. It gives C++ what
JDK gives to Java, standard Python library gives to Python and so on.

It is very good to have standard libraries but if your standard library
breaks compatibility each few month it significantly limits it's target
audience.

> But why not using what boost has to offer inside the
> library, and
> approach the library ABI problem separately?

In CppCMS project I have two parts:

1. Public booster -- boost like libraries I need in the interface.
2. Private (cppcms_boost) -- renamed part of boost that is linked
   statically to my library and has it's own namespace so it would not
   collide with ordinary boost.

So I would like to see something like boost::stable::*
where interfaces keep binary backward compatibility.

> 
> What I find more problematic is the mix of header-only and
> compiled
> libraries
> <snip>
> 

It is same problem. Let's see I have library foo compiled against header
only part of boost-1.55 and it uses shared_ptr in it's interface.

Now come used that uses foo with boost-1.56 with different binary
interface (let's tell mutex replaced with atomic-ops)

Oooops - your application is not thread safe.

BIG Problem.

> 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
>

I think **anything** in tr1 can be binary stabilized and this is 
huge and most important part of Boost.

Also many others can do the same.

Of course I do not expect any library to be binary stable but I do
expect to have some subset of boost libraries to be released separately
as Boost.Stable 

> 
> 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.
> 

Yes, it is problem of any library not connected to binary on programming
interface.

So you cleanup it between major releases once in several years.

> > 
> > - 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]

I would be glad if CMake had replaced boost-build... 

> 
> 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?

Qt is only once example, And BTW qt works quite well with STL...

But take a look on GTKmm? Bad library? And many others. The problem
is that I am as modern library developer limited **not-to-use** boost
**at-all** if I want keep ABI backward compatible.

Artyom