$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: [boost] [Booster] Or boost is useless for library developers
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-05-15 07:09:11
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/refactoring/booster
- 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.