|
|
Boost : |
Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-05-18 07:39:16
Hello Domagoj Saric
Before I start answering each particular point I want to
say in general:
1. Boost is great library, it is one of the best things that happened
to C++.
2. Boost is rather evolutes that follows strict design, this is good
but it is also not so good sometimes.
3. Boost is not free of many deep problem, as an example - total lack of
maintenance releases - upgrade or stay with bugs.
But instead of protecting Boost as "holy" library I suggest - face
existing problems and deal with them and accept that
- Boost is not bug free (and it isn't)
- Boost has some design and maintenance issues.
- Boost does not fit anywhere.
Now lets go to each particular
> For example on the one hand you will complain about the
> design of Boost in
> general and that Boost.ASIO produces code that is too
> big/bloated, while OTOH
> you will praise Qt and claim things like 'virtual functions
> and pimpls have
> negligable efficiency impact'...
> For the simple sake of consistency you simply cannot claim
> _both_ of these
> 'sides'...:
Not right. And I explain why.
Heavy template code produces significantly lager code. So hiding
implementation actually reduces code size and reduces bloat.
Sometimes I just prefer to move some members to pimpl just in order
to prevent inclusion of 10 more useless headers.
Good example is Linux kernel. As policy it does not accept macros
and inline functions in code. (Similar to templates in C++ or in-header
implementations) because it reduces code size and thus significantly
reduces cache misses.
If Linux was written for Modern C++ compiler with "Modern" C++ design
in Boost style, it would probably would not be able to run on
computers with several MB of memory.
> OTOH Qt's
> design and philosophy can
> [snip[ has unclear ownership
> semantics
In Qt, you have quite strict policy of ownership and if you
play by Qt rules you are safe.
Just to remind Qt exists from days where C++ was hopeless kid and
compilers where awful. It developed its own methods and policies
and today is still works very nice with modern design.
> (you still new
> everything and pass around raw pointers hoping you got it
> [snip]
> whose sole core GUI functionality compiles to sizes like
> ~10MB (!? 'sheesh' I
> mean it's only supposed to wrap existing OS functionality)
Just for the record. Nobody says that Qt is problem free, but today
it is one of the best GUI libraries available. And I don't think
that Boost would be ever able to provide something close to it.
Because it just a set of great small libraries and not single bit
framework.
> and at the same time
> complaining about the compiled size of Boost.ASIO just
> fails the consistency
> test...
>
Just for the record: simple HTTP+SCGI+FCGI server that does
trivial things has about 1MB code for logic only compiled with ASIO.
I don't think this is can be good for ASIO.
Qt that provides... Lets see full GUI toolkit and includes all
functionality that boost has+ GUI, opengl, sql, webkit browser in 40MB is not bad at all.
All is matter of how do you look on this.
> Furthermore, even the libraries you mentioned, like Qt, do
> really only of the time interval...And since we are dealing
> with C++ here, your
> much bigger problem is the nonexisting ABI guarantees of
> the language
> itself...in the general case, if you upgrade or change your
> compiler bye bye ABI
> compatiblity...if you really want a stable ABI you'd have
> to go for a C one...
As I mentioned before - GCC keeps its ABI for 6 years, MSVC keeps
ABI in average for 2-3 years. It is far better then 3 month that boost
has.
>
> As has already been suggested, why don't you just simply
> link statically with
> Boost?
Static linking has huge issues:
- Updates require full recompilation
- Each small application that need regex would add 0.7M to its size.
How much bloat do you have!
I don't see any reason today use anything but shared libraries.
We in 2010.
> You must realize that what you are asking from Boost is
> simply not feasible and
> seems reasonable only to you or a subset of Boost
> users...
I'm not asking Boost to become Qt-like library I'm asking to create
an ABI stable subset of most important Boost libraries for example
all in tr1 may become ABI stable easily.
> For example, if I
> understood you correctly, you would even like to have
> shared_ptr<>
> pimpled...
Take a look on following two files:
sp_counted_base.h
sp_counted_base.cpp
http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/branches/refactoring/booster/lib/smart_ptr/src/sp_counted_base.cpp?revision=1185&view=markup
It is the only class I had to change in boost-shared ptr to make it
ABI stable.
How did I this?
1) I moved implementation to library
2) I added pthread_mutex_t to the class even if I do not use it.
3) I removed debug hooks.
Now what happens:
1. I can change the implementation of the counter - use atomic-ops
assembly or OS specific operations without warring about compatibility
because all operations are done in single library.
2. I can add atomic operations on platforms where they were not availible
before without changing layout of class - just by stopping
using pthread_mutex_t.
What does it requires?
1. Linking against some core library.
2. Little thinking about what can happen.
Nothing more! Just to be aware of possible ABI issues.
> In other words...if you dislike the Boost 'philosophy' so
> much, why do you even
> use it..?
Boost has great philosophy - evolution rather then design. But
when some library becomes de-facto standard library in C++ world
and everybody uses it because it is evolved in something great
I expect it become stable, maintainable library with responsibility
to non-bleeding-edge users that boost is targeted for them today.
> ...most of its functionality can be found in
> other libraries (like ACE
> instead of ASIO...)...
1. Boost has better design (I love ASIO API, but I hate compilation
times and bloat)
2. Boost has standardized API - so when you talk about shared_ptr
it is THE shared_ptr
3. Boost has many great libraries (like iostream).
Rephrasing Stoustrup's saying: There are two kinds of libraries
- that everybody hates
- that nobody uses
And sometimes I really hate boost, but it is impossible to leave
without it in modern C++ world.
Artyom
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk