"Artyom" <artyomtnk@yahoo.com> wrote in message news:982320.15795.qm@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