Shared Pointer based Object Pool Implementation with fixed object count
Small nitpicks


The constructor and create could profit from perfect forwarding args (so references of all kinds can be used.

template&lt;typename... E&gt;
Section(size_t size, E&amp;&amp;... args) :
    std::enable_shared_from_this&lt;Section&lt;T&gt;&gt;(),
    m_mem(size, T(std::forward&lt;E&gt;(args)...))
    { /* ... */ }

Do you have any specific reason to prefer std::list&lt;T&gt; over std::vector&lt;T&gt; for m_mem? std::vector&lt;T&gt; would use less memory (no pointers from each element to the next), and the memory used would be contiguous (so iterating over it is very likely faster due to cache effects).


Correctness

Every std::shared_ptr&lt;T&gt; returned by Section&lt;T&gt;::create() might be dangling. This can happen if the Section&lt;T&gt; gets destroyed while there are still std::shared_ptr&lt;T&gt; pointing to contained objects.

This is a result of the std::shared_ptr&lt;T&gt; not owning the pointer.

If you can guarantee that there won't be any std::shared_ptr&lt;T&gt; pointing into the Section&lt;T&gt; when the Section&lt;T&gt; is destroyed, this problem easily disappears.

If this can't be guaranteed, there are two options:


Introducing your own smart pointer type that checks the Section&lt;T&gt; for validity every time it's dereferenced, as the standard smart pointers (std::unique_ptr, std::shared_ptr and std::weak_ptr) are not designed for this task.
(Ab-)using the returned std::shared_ptr&lt;T&gt; to keep the section alive. This can be done in the lamda init capture of the custom deleter.

return std::shared_ptr&lt;T&gt;(obj, [section = shared_from_this()](T *ptr) -&gt; void
{
    section-&gt;destroy(ptr);
    std::unique_lock&lt;std::mutex&gt; lk(section-&gt;m_lock);
    section-&gt;m_objs.push(ptr);
});


Note: This might keep the section alive far longer than intended! (Some might also say that this is an ugly hack...)