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

Subject: Re: [boost] [function] "paranoia" vs efficiency
From: Domagoj Saric (dsaritz_at_[hidden])
Date: 2009-11-07 12:02:21

"Stewart, Robert" <Robert.Stewart_at_[hidden]> wrote in message 
news:DF2E67F3D097004694C8428C70A3FD69046F55F9C0_at_msgbal516.ds.susq.com...
> 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>.

yes it is, if "other_deleter" is in fact the default "dynamic_deleter" class 
that is again in fact only a wrapper around an actual dynamc deleter (>just 
like the current boost::detail::sp_counted_impl_pd<> class is< as said in my 
previous post)...

so if we have

template <typename T, class Deleter = dynamic_deleter>
class my_ptr {...}

then

my_ptr<std::string> onePtr( someStringCreatorFunction(), 
&approprateStringDeleterFunction );
my_ptr<std::string> otherPtr( new std::string( "str" ) ); //will use the 
default deleter/plain delete
...
otherPtr = onePtr;
...

compiles and works just as current shared_ptr<> does...with the added option of 
disabling dynamic deleter functionality _when_ it is not needed....
so simply...the code that needs cross module interoperability simply uses the 
default dynamic_deleter class or explicitly specifies it if it wants to make it 
more clear...and in effect, in that case, you also get the same "shared_ptr<> 
type depends only on the type pointed to" behaviour (because everyone is using 
the same deleter...not _actually_ same but of the same, wrapping, 
type/signature)...

in otherwords you can always go from static to dynamic...but not vice verse...

to make it more on topic...i, think i, proved this true exactly with the 
changes i made to boost::function<>: even with an added policy parameter 
(properly defaulted) existing code compiles and behaves exactly as before...

> Peter Dimov must defend that design decision, if he cares to.

actually not, that was not my point, that decision was perfectly correct...
...my point was just that, even in spite of that correct decision, the goal of 
"creating less bloat" was not achieved (because of other issues outlined in the 
first post)...

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

well there's something from both bowls :) part/most of the changes do not 
need/rely on the changed template signature while others do (the addition of 
policies)...

-- 
 "That men do not learn very much from the lessons of history is the most
important of all the lessons of history."
 Aldous Huxley