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