Smart pointer memory pool
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).