Re: [boost] [Booster] Or boost is useless for library developers

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-05-18 08:00:03

Artyom wrote:
>
> Heavy template code produces significantly lager code. So hiding
> implementation actually reduces code size and reduces bloat.

Ridiculous.  Misuse of templates can do so, but I doubt you'll find (m)any examples in Boost.  Templates expose more code to the compiler permitting otherwise impossible optimizations.  Expression templates, for example, eliminate tremendous runtime code and overhead utterly impossible to do otherwise.

> Sometimes I just prefer to move some members to pimpl just in order
> to prevent inclusion of 10 more useless headers.

Preference.

> 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.

Generalizations are useless.  Profiling is the only way to know which particular design and implementation decisions are appropriate for a given use case.  Inlining can be overused easily, of course, but not doing so can be just as bad.

> 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.

Unsubstantiated conjecture.

> > As has already been suggested, why don't you just simply
> > link statically with
> > Boost?
>
> Static linking has huge issues:
>
> - Updates require full recompilation

That's a huge issue?

> - Each small application that need regex would add 0.7M to its size.
>   How much bloat do you have!

How much does the alternative regex library you use add to an application?

> I don't see any reason today use anything but shared libraries.
> We in 2010.

There are many good reasons to use static libraries, but that's irrelevant to this discussion.

> > 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.

That isn't Boost's purpose, so it is highly unlikely to occur.

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

So, you increased the size, decreased the performance, and removed functionality.  The result isn't shared_ptr.

It is possible that shared_ptr could have been designed with conditional compilation to choose a header-only or shared library implementation, but that would have been harder to maintain and would have prevented interoperation between applications and libraries trying to mix them.

> 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.

Of course that's all possible, but you aren't using boost::shared_ptr.

> > 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.

So, you like that Boost races along the bleeding edge of C++ development, producing advanced, even state-of-the-art designs that are considered for standardization, but you'd also like it to be stable.  I'm confused.

I get that it would be nice to have maintenance releases that include backported bug fixes so that one could continue to use older releases for a longer period rather than chasing the latest release to get bug fixes.  That would ensure longer lived ABI compatibility.  That much I can see being considered.  The rest is just antithetical to Boost.

> 2. Boost has standardized API - so when you talk about shared_ptr
>    it is THE shared_ptr

Except when you rewrite it and pretend the result is still boost::shared_ptr.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.