std::shared_ptr<Object> p1 = std::make_shared<Object>("foo");
std::shared_ptr<Object> p2(new Object("foo"));
I am not able to understand why make_shared is more efficient than directly using shared_ptr.
I need a step by step explanation of the sequence of objects created and operations done by both, so that I understand how make_shared is efficient. I have given one example above for reference.
The difference is that std::make_shared performs one heap-allocation, whereas calling the std::shared_ptr constructor performs two.
std::shared_ptr manages two entities:
std::make_shared performs a single heap-allocation accounting for the space necessary for both the control block and the data. In the other case, new Obj("foo") invokes a heap-allocation for the managed data and the std::shared_ptr constructor performs another one for the control block.
For further information, check out the implementation notes at cppreference.
NOTE (2019/08/30): This is not a problem since C++17, due to the changes in the evaluation order of function arguments. Specifically, each argument to a function is required to fully execute before evaluation of other arguments.
Since the OP seem to be wondering about the exception-safety side of things, I've updated my answer.
Consider this example,
void F(const std::shared_ptr<Lhs> &lhs, const std::shared_ptr<Rhs> &rhs) { /* ... */ }
F(std::shared_ptr<Lhs>(new Lhs("foo")),
std::shared_ptr<Rhs>(new Rhs("bar")));
Because C++ allows arbitrary order of evaluation of subexpressions, one possible ordering is:
new Lhs("foo"))new Rhs("bar"))std::shared_ptr<Lhs>std::shared_ptr<Rhs>Now, suppose we get an exception thrown at step 2 (e.g., out of memory exception, Rhs constructor threw some exception). We then lose memory allocated at step 1, since nothing will have had a chance to clean it up. The core of the problem here is that the raw pointer didn't get passed to the std::shared_ptr constructor immediately.
One way to fix this is to do them on separate lines so that this arbitary ordering cannot occur.
auto lhs = std::shared_ptr<Lhs>(new Lhs("foo"));
auto rhs = std::shared_ptr<Rhs>(new Rhs("bar"));
F(lhs, rhs);
The preferred way to solve this of course is to use std::make_shared instead.
F(std::make_shared<Lhs>("foo"), std::make_shared<Rhs>("bar"));
std::make_sharedQuoting Casey's comments:
Since there there's only one allocation, the pointee's memory cannot be deallocated until the control block is no longer in use. A
weak_ptrcan keep the control block alive indefinitely.
weak_ptrs keep the control block alive?There must be a way for weak_ptrs to determine if the managed object is still valid (eg. for lock). They do this by checking the number of shared_ptrs that own the managed object, which is stored in the control block. The result is that the control blocks are alive until the shared_ptr count and the weak_ptr count both hit 0.
std::make_sharedSince std::make_shared makes a single heap-allocation for both the control block and the managed object, there is no way to free the memory for control block and the managed object independently. We must wait until we can free both the control block and the managed object, which happens to be until there are no shared_ptrs or weak_ptrs alive.
Suppose we instead performed two heap-allocations for the control block and the managed object via new and shared_ptr constructor. Then we free the memory for the managed object (maybe earlier) when there are no shared_ptrs alive, and free the memory for the control block (maybe later) when there are no weak_ptrs alive.
make_shared as well: since there's only one allocation, the pointee's memory cannot be deallocated until the control block is no longer in use. A weak_ptr can keep the control block alive indefinitely. –
Feinberg reset() on the shared_ptr then even the control block is reset, in case of make_shared? is this also the case in direct creation? –
Blindstory reset() will decrement the shared_ptr count in the control block in both cases. Is that what you meant by "control block is reset"? –
Gildea make_shared and make_unique consistently, you won't have owning raw pointers an can treat every occurrence of new as a code smell. –
Fig reset(), when using make_shared()?. –
Blindstory shared_ptr, and no weak_ptrs, calling reset() on the shared_ptr instance will delete the control block. But this is regardless or whether make_shared was used. Using make_shared makes a difference because it could prolong the life-time of the memory allocated for the managed object. When the shared_ptr count hits 0, the destructor for the managed object gets called regardless of make_shared, but freeing its memory can only be done if make_shared was not used. Hope this makes it more clear. –
Gildea valgrind to observe the number of allocations. –
Gildea reset() 2) How do you assign a pointer to an array (no std::array) to std::unique_ptr without using new? –
Hoyden weak_ptr has its own control block, or it simply refer to share_ptr's control block? Your comment seems to indicate the latter, just want to confirm. :D –
Wallacewallach shared_ptrs and weak_ptrs that denote that same allocation share the same control block. Which incidentally makes owner_less work. –
Feinberg Update I: Exception-Safety part is invalid. Compiler can't partially evaluate arguments of F. If argument is evaluated then it must be complete evaluation. So shown order of evaluation is impossible and this example and explanation is invalid. AFAIK current implementation of shared_ptr do not have problem with exception safety when instantiate shared_ptr (some old version had this issue when allocating object was successful, but allocating control block failed). –
Shotwell char * p = malloc(sizeof(T) + sizeof(control)); T * t = new(p) T(args...); control * c = new(p + sizeof(T)) control(1, 0);. i.e. placement-new –
Recede make_shared) is safer from weak_ptr perspective comparing to calling shared_ptr constructor directly using new. Using new leaves a small (or large?) window where weak_ptr will hold the lock on control block while the actual data block on heap has been freed. –
Tepic There is another case where the two possibilities differ, on top of those already mentioned: if you need to call a non-public constructor (protected or private), make_shared might not be able to access it, while the variant with the new works fine.
class A
{
public:
A(): val(0){}
std::shared_ptr<A> createNext(){ return std::make_shared<A>(val+1); }
// Invalid because make_shared needs to call A(int) **internally**
std::shared_ptr<A> createNext(){ return std::shared_ptr<A>(new A(val+1)); }
// Works fine because A(int) is called explicitly
private:
int val;
A(int v): val(v){}
};
new, otherwise I would have used make_shared. Here is a related question about that: #8147527. –
Keramics friend? –
Oday make_shared, and they are implementation-specific. –
Benis The shared pointer manages both the object itself, and a small object containing the reference count and other housekeeping data. make_shared can allocate a single block of memory to hold both of these; constructing a shared pointer from a pointer to an already-allocated object will need to allocate a second block to store the reference count.
As well as this efficiency, using make_shared means that you don't need to deal with new and raw pointers at all, giving better exception safety - there is no possibility of throwing an exception after allocating the object but before assigning it to the smart pointer.
I see one problem with std::make_shared, it doesn't support private/protected constructors
std::shared_ptr(new T(args...)) may call a non-public constructor of T if executed in context where it is accessible, while std::make_shared requires public access to the selected constructor.
https://en.cppreference.com/w/cpp/memory/shared_ptr/make_shared#Notes
If you need special memory alignment on the object controlled by shared_ptr, you cannot rely on make_shared, but I think it's the only one good reason about not using it.
Shared_ptr: Performs two heap allocation
Make_shared: Performs only one heap allocation
I think the exception safety part of mr mpark's answer is still a valid concern. when creating a shared_ptr like this: shared_ptr< T >(new T), the new T may succeed, while the shared_ptr's allocation of control block may fail. in this scenario, the newly allocated T will leak, since the shared_ptr has no way of knowing that it was created in-place and it is safe to delete it. or am I missing something? I don't think the stricter rules on function parameter evaluation help in any way here...
About efficiency and concernig time spent on allocation, I made this simple test below, I created many instances through these two ways (one at a time):
for (int k = 0 ; k < 30000000; ++k)
{
// took more time than using new
std::shared_ptr<int> foo = std::make_shared<int> (10);
// was faster than using make_shared
std::shared_ptr<int> foo2 = std::shared_ptr<int>(new int(10));
}
The thing is, using make_shared took the double time compared with using new. So, using new there are two heap allocations instead of one using make_shared. Maybe this is a stupid test but doesn't it show that using make_shared takes more time than using new? Of course, I'm talking about time used only.
© 2022 - 2024 — McMap. All rights reserved.
make_sharedyou can writeauto p1(std::make_shared<A>())and p1 will have the correct type. – Ufoshared_ptrs in a single function call might run bothnews before wrapping either; if the second fails, the first one is leaked. – Zhdanov