Difference in make shared and normal shared ptr in C

Question

std  shared ptr lt Object gt  p1   std  make shared lt Object gt   foo    std  shared ptr lt Object gt  p2 new Object  foo       Many google and stackoverflow posts are there on this  but I am not able to understand why make shared is more efficient than directly using shared ptr    Can someone explain me step by step sequence of objects created and operations done by both so that I will be able to understand how make shared is efficient  I have given one example above for reference

User · Answer

Shared ptr  Performs two heap allocation   Control block reference count  Object being managed   Make shared  Performs only one heap allocation   Control block and object data

User · Answer

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

User · Answer

The difference is that std  make shared performs one heap-allocation  whereas calling the std  shared ptr constructor performs two   Where do the heap-allocations happen   std  shared ptr manages two entities    the control block  stores meta data such as ref-counts  type-erased deleter  etc  the object being managed   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   Update I  Exception-Safety  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 lt Lhs gt   amp lhs  const std  shared ptr lt Rhs gt   amp rhs                 F std  shared ptr lt Lhs gt  new Lhs  foo       std  shared ptr lt Rhs gt  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 lt Lhs gt  std  shared ptr lt Rhs gt    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 lt Lhs gt  new Lhs  foo     auto rhs   std  shared ptr lt Rhs gt  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 lt Lhs gt   foo    std  make shared lt Rhs gt   bar       Update II  Disadvantage of std  make shared  Quoting 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 ptr can keep the control block alive indefinitely    Why do instances of 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   Back to std  make shared  Since 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

User · Answer

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  lt  30000000    k           took more time than using new     std  shared ptr lt int gt  foo   std  make shared lt int gt   10           was faster than using make shared     std  shared ptr lt int gt  foo2   std  shared ptr lt int gt  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

User · Answer

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

User · Answer

I see one problem with std  make shared  it doesn t support private protected constructors

User · Answer

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 lt  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

User · Answer

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 lt A gt  createNext    return std  make shared lt A gt  val 1            Invalid because make shared needs to call A int    internally        std  shared ptr lt A gt  createNext    return std  shared ptr lt A gt  new A val 1             Works fine because A int  is called explicitly  private       int val       A int v   val v

[c++] Difference in make_shared and normal shared_ptr in C++

Examples related to c++

Examples related to c++11

Examples related to shared-ptr