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

Subject: Re: [boost] [Booster] Or boost is useless for library developers
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-05-18 08:30:25

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

Take a look on this message:

http://lists.boost.org/Archives/boost/2010/03/163468.php

> > - Updates require full recompilation
> 
> That's a huge issue?

Yes when you have 3rd part library without sources with bug
in old version of static library it linked with which was solved 
long time ago but you can't change it because it uses static library.

What would happen of libstdc++ was statically linked or even libc?

Bad things.

And boost becomes today as important as libstdc++.


> > - 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 mean that I prefer to use shared libraries - they reduce memory 
use, bloat because they are actually shared.

So adding shared library virtually does not add any overhead.


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

How did I decreased performance? By calling function 
instead of in-lining it? Just for the record atomic ops cost
hundreds of cycles so function call is negligible. Not talking
about a fact that every unit uses same code cached in memory. 

How did I removed functionality (this is really interesting?)


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

You can always have boost::abi::shared_ptr


> 
> Of course that's all possible, but you aren't using
> boost::shared_ptr.
>
> [SNIP]
>
> > 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.
> 

boost::shared_ptr, std::tr1::shared_ptr, std::shared_ptr
and my booster::shared_ptr is same pointer as it has same interface
and same semantics - that what is important.

Exactly as STLPort's auto_ptr, libstdc++'s auto_ptr, apache stdcxx's
auto_ptr is same auto_ptr with same semantics.

I don't see any difference.


Artyom