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