Smart pointer memory pool I'm using a third-party library which utilizes boost::shared_ptr for memory management.

The problem is that I need to allocate many objects and I have detected that the allocation and deallocation is rather resource-demanding. So I thought I should utilize a smart-pointer memory pool to reduce the overhead.

#include &lt;boost/smart_ptr/make_shared_array.hpp&gt;

template &lt;class T, size_t pool_size&gt;
class shared_ptr_pool
{
   boost::shared_ptr&lt;T[]&gt; pool;
   size_t avail = 0;

public:
   boost::shared_ptr&lt;T&gt; make_shared()
   {
      if (!avail)
      {
         pool = boost::make_shared&lt;T[]&gt;(pool_size);
         avail = pool_size;
      }

      return boost::shared_ptr&lt;T&gt;(pool, &amp;pool[--avail]);
   }
};


The solution is to utilize make_shared for arrays and the shared_ptr aliasing constructor. The solution in inherently thread-unsafe, but for my needs that is okay.

Any thoughts, comments or pretty much anything would be appreciated.
Per the comments, this isn't really a "pool" because things don't go back into it when you're done using them. It's just an "incremental allocator" that does allocation in "chunks". A better name for it might be shared_ptr_chunk_allocator (and chunk_size instead of pool_size).

Given that pool_size is used only on the codepath that also allocates memory (so it's not a super speed-critical path where one more memory load would hurt performance), and shared_ptr_pool&lt;...&gt; has non-static data members (so there's no harm in adding one more non-static data member), surely it would make more sense to make pool_size a runtime parameter to shared_ptr_pool's constructor.

// your current code:
shared_ptr_pool&lt;myclass, 16&gt; pool;
// versus my suggestion:
shared_ptr_pool&lt;myclass&gt; pool(16);


This would even allow you to provide a member function for modifying the chunk size on the fly, in case maybe your code could detect that its particular workload demanded a bigger chunk size.

if (memory_usage_low &amp;&amp; still_spending_lots_of_time_in_allocation) {
    pool.set_chunk_size(pool.chunk_size() * 2);
}


The actual code implementation looks fine to me; nothing to complain about there. :)

You might be pleased to (or, you might already) know that std::shared_ptr&lt;T[]&gt; is part of the Library Fundamentals v1 Technical Specification, which I think means it ought to be coming to C++1z. However, it's not in the working draft yet as of N4567 (November 2015).