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