Re: [boost] [function] "paranoia" vs efficiency

Subject: Re: [boost] [function] "paranoia" vs efficiency
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2009-11-02 14:43:16

Domagoj Saric wrote:
> "Stewart, Robert" <Robert.Stewart_at_[hidden]> wrote in message
> news:DF2E67F3D097004694C8428C70A3FD69046F261514_at_msgbal516.ds.s
usq.com...
> > Domagoj Saric wrote:
> >> documentation states that shared_ptr uses a more joe sixpack
> >> approach with a
> >> "forced" dynamic deleter on purpose, to achieve a simpler
> >> interface and a more
> >> 'stable' abi (the point seems moot imho, the same could be
> >> achieved with
> >> default template parameters while retaining compile-time
> >> configurability)...
> >
> > The same could not be achieved with defaulted template arguments.
> > The idea is that, regardless of how something is allocated
> > and deleted,
> > the shared_ptr type only depends upon the type it points to.
>
> i realize that but can't the same be achieved with a
> template-parameter-specified deleter that is in fact a
> dynamic deleter? the

As soon as you specialize the class template with anything other than the default deleter type, you have a different type.  shared_ptr<T> is shared_ptr<T>, even if they use different deleters.  your_ptr<T> isn't your_ptr<T,other_deleter>.

> what i'd like is (like in all things) to have the option of
> using the power
> (you mentioned in your example) of a more stable/type only
> dependent ABI _when
> i actually need it_ and also being free of virtual
> functions/indirect calls
> (and maybe/possibly even rtti) when i do not need it (which
> "i bet" is the vast majority of shared_ptr<> uses "out
> there")...

What you want is something other than shared_ptr.  It doesn't allow that flexibility, so shared_ptr's are, by design, interoperable.

> >> the boost::function documentation states that virtual
> >> functions are not used
> >> because they cause code bloat but comparing the actual
> >> binaries and code
> >> generated i found boost::function to actually be worse in
> >> that respect than the
> >> std::tr1::function implementation provided with msvc++ 9.0
> >> SP1 (that does use virtual functions)...
> >
> > The claim was made years ago and is for a library that doesn't
> > have the benefit of being written by those with direct
> > access to those
> > writing the compiler.  It may be that things have changed
> > and that another
> > approach is superior now, as your analysis of
> > std::tr1::function in MSVC 9 SP1 suggests.
>
> well the stl shipped with msvc (9) is provided by dinkumware,
> not ms, and can
> be bought separately from the msvc++ compiler...and as such
> does not use some
> particular 'msvc++ specific' tricks...not that i know of

I wouldn't be surprised but what they had pretty easy access to those inside MS given that they were providing the STL for MS at that time.  Still, I merely suggested a possibility.  Peter Dimov must defend that design decision, if he cares to.

> ...there are however many other implementation details that
> can be done
> differently (or be made subject to configurability) while
> retaining standard
> compliancy...and this is what i tried to do...and according
> to performed tests
> the result is better than both dinkumware and the current
> boost implementation
> in both space and time efficiency with added configuration power... ;)

Those are great so long as they don't break with Peter's design ideals for the class.  Otherwise, you optimize it into being a different class template.

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