Are there any downsides with using make_shared to create a shared_ptr

Question

Are there any downsides with using make_shared<T>() instead of using shared_ptr<T>(new T).

Boost documentation states

There have been repeated requests from users for a factory function that creates an object of a given type and returns a shared_ptr to it. Besides convenience and style, such a function is also exception safe and considerably faster because it can use a single allocation for both the object and its corresponding control block, eliminating a significant portion of shared_ptr's construction overhead. This eliminates one of the major efficiency complaints about shared_ptr.

Answer 1

I know of at least two.

• You must be in control of the allocation. Not a big one really, but some older api's like to return pointers that you must delete.
• No custom deleter. I don't know why this isn't supported, but it isn't. That means your shared pointers have to use a vanilla deleter.

Pretty weak points. so try to always use make_shared.

Answer 2

In addition to the points presented by Caspin, even weaker one:

• If you use weak_ptrs that live after all the shared_ptrs to a given object have died, then this object will live in memory along with the control block until the last weak_ptr dies.