Re: [boost] [smart_ptr] release()

From: Phil Bouchard (philippe_at_[hidden])
Date: 2008-08-31 14:56:28

"Peter Dimov" <pdimov_at_[hidden]> wrote in message 
news:00e401c90b0d$2994d570$6507a80a_at_pdimov2...
> Phil Bouchard:
>
>> Interesting but unfortunate we cannot mix pools within allocators because 
>> it makes allocators even less flexible (useful).
>
> You can mix pools, but all copies must share the same pool. A conforming 
> allocator should not contain the pool itself, but a pointer to the pool. 
> Two allocators should compare equal when they point to the same pool.
>
> It doesn't make much sense for each shared_ptr to use its own private pool 
> anyway. shared_ptr only allocates once.

If we take a better allocator example having multiple pools, having searches 
starting with the fastest one (stack).  Here's the pseudo-code:

template <typename T>
    class quick_allocator
    {
        auto_pool * pa_;
        boost::thread_specific_ptr< boost::pool<> > pb_;

        ...
        void * allocate(std::size_t s)
        {
            void * p = 0;

            if (p = pa_->alloc(s)) // 1) stack array of fixed size
                return p;

            if (p = pb_->ordered_malloc(s)) // 2) thread local heap
                return p;

            if (p = ::operator new (s)) // 3) system heap
                return p;

            return p;
        }
    };

Two pointers here will have to be copied on each sp_counted_impl_pda object 
(sizeof(pb_) == sizeof(void *) with pthreads).  It's not too bad when we use 
pointers but hopefully there will be some assertion preventing usage of 
pools not following the new standards inside shared_ptr, because my own 
internal sh_owned_base_nt.hpp pool never considered this and the mistake can 
easily be propagated.

-Phil