"Peter Dimov" <pdimov@pdimov.com> wrote in message news:00e401c90b0d$2994d570$6507a80a@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