Boost logo

Boost :

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2010-05-18 06:21:48


"Artyom" <artyomtnk_at_[hidden]> wrote in message
news:982320.15795.qm_at_web36701.mail.mud.yahoo.com...
Hello,
> That is not a first time I bring up this issue.

Exactly, and I must say I am still puzzled by the line of some of your arguments
so far...
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'...:
 - Boost is praised precisely for its design by leading figures of the 'C++
world' and it has acted as the incubator for functionality that eventualy got
included into the standard library itself...OTOH Qt's design and philosophy can
for the most part be described as downright horrible, it is not exception safe
('lives' in some fantasy single-process infinite memory world), sometimes does
not even assert that an OS API call succeeds (much less error-handle it), uses
non standard tools and macros, has unclear ownership semantics (you still new
everything and pass around raw pointers hoping you got it right who or what will
eventually delete it, they have just relatively recently started to learn the
basics of RAII, and of course went and reinvented the umpteenth smart
pointer), if I rember correctly even in verion 4.5 I could still find places
where they checked for null return from new.......
 - the 'negligable efficienty impact' claim is just plain wrong as proven
exactly by Qt...it is quite more than enough to investigate the horrifying
amount of code that gets executed and memory chunks that get allocated for each
and every window message that your application receives even if no widget wants
it or handles it (it finally gets 'eaten' by an empty virtual function in some
base class) _precisely_ because of the injudicious (ab)use of virtual functions
and pimpls (along with other such 'wonderful and negligable' idioms that I like
to call optimizer brickwalls).....in other words praising a library like Qt
whose sole core GUI functionality compiles to sizes like ~10MB (!? 'sheesh' I
mean it's only supposed to wrap existing OS functionality) and at the same time
complaining about the compiled size of Boost.ASIO just fails the consistency
test...

Furthermore, even the libraries you mentioned, like Qt, do not provide
'infinite' backward compatiblity...i.e. Qt 5 will break the ABI compatiblity
with Qt 4...So you are pretty much forced to the updates anyway...the issue is
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 has already been suggested, why don't you just simply link statically with
Boost? One of the many good sides of efficiently and tightly written libraries
is that you can just simply link statically (not that I am claiming that all of
Boost fits into that category, unfortunately it does not...but compared to
Qt......)...

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...For example, if I
understood you correctly, you would even like to have shared_ptr<>
pimpled...while for example to me personally this idea is 'alarming' if not
'criminal' because I don't like shared_ptr<> various overheads even as it is...I
doubt that even Qt will eventually pimpl its variant of shared_ptr...

In other words...if you dislike the Boost 'philosophy' so much, why do you even
use it..? ...most of its functionality can be found in other libraries (like ACE
instead of ASIO...)...

--
"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than from
one whose countenance exudes suspicion and hate."
Neil Postman 

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk