Re: [boost] Re: shared_ptr: unsafe, or am I crazy?

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-01-18 16:30:02

----- Original Message -----
From: "George A. Heintzelman" <georgeh_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, January 18, 2002 3:52 PM
Subject: Re: [boost] Re: shared_ptr: unsafe, or am I crazy?

>
> Peter Dimov wrote:
> > George Heintzelman wrote:
> > > I don't like adding the extra layer of indirection for *all*
shared_ptr
> > > destructor calls, in order to 'solve' this, for the destructor case
> > > only. In a policy-based smart pointer, I would support making it an
> > > available policy but not the default one.
> >
> > I'd be surprised if you could measure the added cost. Besides, the extra
> > layer of indirection has other good uses. It makes it possible to pass
> > shared_ptr<>s across exe/dll boundaries (that use different heaps.)
>
> Most times I'm sure you're right. I'm mostly concerned with the cases
> where the cases where the data members of the pointed-to object are all
> simple types, requiring no destructor calls, or ones with similarly
> simple inline destructors; then the C++ implementation can completely
> optimize away function calls except for the deallocation. I suspect
> that the layer of indirection here will make it much more unlikely for
> compilers to perform that optimization.

I think it's reasonable to expect that in Peter's case, the final
destruction will be optimized down to the equivalent of:

1. p <= pointer to counter
2. decrement p.count
3. test p.count
4. call p.deallocate
5.    which calls the memory deallocator

> With shared_ptr's being a commonly recommended way for dynamically
> storing things in vectors without copying the data, I think this may
> occur fairly often. Just looking over my personal code, I have several
> examples of such vectors. It just seems a violation of the
> no-use-no-pay rule.

I agree that it would be best to make this a parametrizable feature of
smart_ptr, but I think you may not be looking in the right place for
optimizations. You can only eliminate step 4. above if you're using a
shared_ptr. Given the amount of (shallow) copying that can happen in a
vector, if you're really worried about speed and/or code size you'll store
raw pointers instead, and manage them with a wrapper around the vector. I
guess I'm saying: don't overplay the amount you'd overpay ;-)

-Dave