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:51:35

Artyom wrote:
>
> > 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

Asio addressed such issues in 1.43.  Has that resolved the problem you mentioned?  Furthermore, did you test performance of the two designs?  That is, what was the performance cost of using pimpls versus not?  It is often reasonable to trade space for performance.

Saying that a header only library can lead to code bloat is one thing.  Blaming it on templates generally is another.  You can argue whether header only is appropriate for a particular use case, but it has its merits, too.

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

That's not a problem with the approach I described previously.

> What would happen of libstdc++ was statically linked or even libc?
>
> Bad things.
>
> And boost becomes today as important as libstdc++.

Boost isn't designed to be a single, system-wide source of functionality for a wide array of libraries and applications.  To do so would make it something else entirely.

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

Boost.Regex builds a shared library.

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

I didn't look at the code you changed.  Perhaps the specific change you made was as appropriate as you describe.  I merely commented on the fact that you moved code out of line that I assumed Peter had inlined appropriately for performance reasons.

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

If you remove functionality, you change the design.  Whether you think the removed functionality is "really interesting" is not the point.

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

Someone has to create and maintain it.

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

Just as was mentioned before, you cannot have different act-alike shared_ptrs share the same memory because they don't manage the reference count the same way.  Therefore, you must copy the data, rather than share it, when moving from one to another.

auto_ptr's don't share data.  Using the same type to copy means transferring ownership.  Transferring from one auto_ptr implementation to another requires manual intervention.

They don't work well together.  There is a significant difference.

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