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 http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/branches/refactoring/booster/booster/smart_ptr/sp_counted_base.h?revision=1172&view=markup 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