Hello, I want to bring up an important issue that boost developers are not aware of: anybody who develops a library and wants to keep any kind of backward compatibility can-not use Boost. Issue, let's assume I want to develop a small library that keeps backward comparability well. 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. That is not a first time I bring up this issue. But at this point I started to bring a some kind of solution. I do need boost for my FOSS project CppCMS <http://cppcms.sf.net>. I was trying for a long period use renamed version of Boost (with a small tool I written similar to BCP's renamer) inside the library not showing the interface outside but finally I realized that I need boost in interface. I need ASIO, I need shared_ptr, I need regex, I need thread and much more... So I created a small library I called "booster" as part of CppCMS project that has a goal - provide backward compatible and stable boost like library that can be used by other libraries. It has following libraries: - smart_ptr: intrusive_ptr, shared_ptr, - function - locale (full copy of Boost.Locale I develop) - regex (pcre-wrapper, no replace functionality, no wide api) - system (meanwhile without error_condition) - thread (partial) - aio - my own ASIO like library. - ptime - Posix time (very different from boost one) For this purposes I did: - Adopted some of boost code to booster (shared_ptr/intrusive_ptr) and made sure that it would not break ABI with internal changes. - Wrapped pthreads with boost.thread like interface (in any case boost.thread is more like pthreads with C++ interface). So under windows it requires pthreads-win32 library. - I wrapped pcre library with boost.regex like interface. - I had written my own Boost.Asio like library (Booster.AIO) that has very limited use of templates. It uses epoll/devpoll/kqueue where available and poll or select on other platforms (no IOCP as it adds many limitations). - It uses CMake instead of Boost.Build. - It supports **only** modern compilers: gcc>=3.4, MSVC-2008 (2005 should work as well, but not tested), intel 11 compiler. - It is little bit less Windows friendly then Boost - no auto-link, no wide api, no IOCP support. Believe me it wasn't simple decision to start writing this library. But I just had no other choice. ------------------------------------------------ The source code can be found there (svn): https://cppcms.svn.sourceforge.net/svnroot/cppcms/framework/branches/refacto... - I do not encourage anybody use it over boost, but if you have similar problems with boost as I have, you are welcome to take a look on it, try it. - I do think that boost is great library. - I would really prefer to use boost if it was not breaking ABI every few month. - I would probably adopt more boost libraries into booster (where possible) ------------------------------------------------------------- I want boost community to think about it... Is it right that developers of many libraries can't use Boost. Think of GTKmm, think of Qt, think of kdelib - that no-one can use it just because they promise backward compatibility. Maybe there is something wrong with it? Artyom.