Explore the efficiency of make_shared

Why Make_shared?

C++11 introduced smart pointers, and there is also a template function std::make_shared that returns a std::shared_ptr of a specified type, which is the same asstd::shared_ptr What benefits can it bring us over the constructor?

Benefits

More efficient

shared_ptr Need to maintain reference count information,

• A strong reference to keep track of how many live shared_ptrs are currently holding the object. The shared object will be destroyed (and possibly released) when the last strong reference leaves.
• Weak reference, used to record how many weak_ptrs are currently observing the object. When the last weak reference leaves, the shared internal information control block will be destroyed and released (the shared object will also be released, ifIf it has not been released yet).

If you allocate the object by using the original new expression and then pass it to the shared_ptr (that is, using the shared_ptr constructor), the shared_ptr implementation has no choice but to allocate the control block separately:

12	auto p = new widget();shared_ptr sp1{ p }, sp2{ sp1 };

If you choose to use make_shared, the situation will become as follows:

1	auto sp1 = make_shared(), sp2{ sp1 };

The action of memory allocation can be done all at once. This reduces the number of memory allocations, which are expensive operations.

About the performance test of the two methods can be seen here Experimenting with C++ std::make_shared

Exception safe

Look at the code below:

1234	void F(const std::shared_ptr& lhs, const std::shared_ptr& rhs) { /* ... */ }F(std::shared_ptr(new Lhs("foo")),std::shared_ptr(new Rhs("bar")));

C++ does not guarantee the evaluation order of parameters and the evaluation order of internal expressions, so the possible execution order is as follows:

1. new Lhs("foo"))
2. new Rhs("bar"))
3. std::shared_ptr
4. std::shared_ptr

Ok, now let's assume that an exception is thrown in the second step (such as out of memory, in short, the Rhs constructor is abnormal), then the memory of the Lhs object applied for in the first step is leaked. ThisThe core of the problem is that shared_ptr does not get the raw pointer immediately.

We can fix this problem as follows.

123	auto lhs = std::shared_ptr(new Lhs("foo"));auto rhs = std::shared_ptr(new Rhs("bar"));F(lhs, rhs);

Of course, the recommended practice is to use std::make_shared instead:

1	F(std::make_shared("foo"), std::make_shared("bar"));

Disadvantages

Cannot use make_shared when the constructor is protected or private

make_shared is good, but there are some problems, for example, when the object I want to create does not have a public constructor, make_shared cannot be used, of courseWe can use some little tricks to solve this problem, like here How do I call ::std::make_shared on a class with only protected or private constructors?

The memory of the object may not be reclaimed in time

make_shared allocates memory only once, which seems fine. Reduces memory allocation overhead. Here comes the problem, weak_ptr keeps control blocks (strong references, andWeak reference information) life cycle, and therefore keep the memory allocated by the object, the memory will be released only when the last weak_ptr leaves the scope. When the original strong reference is reduced to 0The memory that can be released has now become a strong reference. If the reference is reduced to 0, it can be released, which unexpectedly delays the time of memory release. This is a problem that needs attention for scenarios with high memory requirements. About this issueSee here make_shared, almost a silver bullet

Reference

• GotW #89 Solution: Smart Pointers
• cppreference.com – std::make_shared