Re: [boost] More scoped_ptr ruminations

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-21 17:48:54

From: "Greg Colvin" <Gregory.Colvin_at_[hidden]>
> At 01:55 PM 9/21/2002, you wrote:
> >From: "David Abrahams" <dave_at_[hidden]>
> >...
> >
> >> > > 1. Should we think about optimizing away storage for the deleter
when
> >> it's
> >> > > known to be stateless?
> >> >
> >> > We might, although I'm not convinced that it's worth it.
> >>
> >> If we started using pool allocation as an optimization it might be.
> >
> >Pool allocation is another optimization that I'm not fond of. :-)
>
> A fairly painless step in that direction would be to use
> std::allocator instead of std::operator new to allocate
> handles.

I think that it might prove somewhat painful, as shared_ptr allocates
objects of different types (counted_base_impl<P, D>) and a std::allocator<T>
can only allocate T. boost::pool is not limited to a type, but it's limited
to a size. Intrusively counted objects (derived from counted_base) present
another problem as they are allocated by the user.

I'm sure that It Can Be Done, but in my opinion, if heap
allocation/deallocation is a problem for the count, it will be a problem for
user types as well; many implementations already have good allocators that
typically maintain a pool for small objects and outperform portable pool
allocators, and where this is not the case, programmers install a
replacement (or override the global operator new.) The only reason to
attempt the optimization is "proof of concept" but this will reduce code
readability a lot, and people do attempt to read the shared_ptr source.

I like to think of shared_ptr.hpp as a reference implementation: good enough
for real world use, but clear enough to be easily understood.