Re: [boost] More scoped_ptr ruminations

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-09-21 18:20:49

At 04:48 PM 9/21/2002, you wrote:
>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.

I'm convinced.  KISS.