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 13:40:46

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

Well, when I started using boost, I limited myself on the header-only
ones so I could deploy the application code on systems without boost
installed by simply bundling the headers, without having to bother
with integrating the build system. There was still much useful
functionality to get out of boost.

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

I'd say the audience which appreciates state-of-the-art C++
programming paradigms as found in boost _is_ significantly different
from the audience more traditional programming paradigms have. And it
seems like this audience actually sees the things that make boost
unique as an advantage.

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

I hear you. I'm just saying that in the cases where I need a
stable ABI, I rather go for interfacing glue than for a library fork.

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

I was referring to the case where I keep the volatile boost code
completely out of the interface. In this case I do not have the
problem you are referring to, but I can get a problem with boost's
shared 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
> >
> 
> I think **anything** in tr1 can be binary stabilized and this is 
> huge and most important part of Boost.
> 

Sure, it can be done. But it would sacrifice the huge possibilities
for future improvements which are possible by limiting to source
compatibility.

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

I fully agree. But for now, I'd be even grateful if CMake found
its way back into the official boost tree. And I believe this is more
likely if the existing CMake-based boost codebase is up-to-date.

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

It works with STL, but it still provides its own replacements for most
of STL. This is why I immediately believe if they claim they are fully
backwards-compatible. But it is also why I wonder if striving for that
goal is a good thing.

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

GTKmm uses STL in its interfaces. So their ABI compatibility can only
go as far as the STL ABI compatibility is maintained. If they used
boost, they would stay equally compatible as long as you don't
change your system boost.

Best regards,

Isidor