1.1.10.7 make function

• make_unique doesn’t joined the Standard Library until c++14.
• make_unique just perfect-forwards its parameters to the constructor of the object being created, constructs a std::unique_ptr from the raw pointer new produces, and returns the std::uniqu_ptr so created. make_unique doesn’t support arrays or custom deleters.
• std::make_unique and std::make_shared are two of the three make functions: functions that take an arbitrary set of arguments, perfect-forward them to the constructor for a dynamically allocated object, and return a smart pointer to that object. The third make function is std::allocate_shared
• make function has tree advantage: simply, exception safety and allocate once for efficiency.
  1. The method of using new repeat the type being created, but the make functions don’t. The second reason to prefer make functions has to do with exception safety.
     auto upw1(std::make_unique<Widget>()); // with make func 
     std::unique_ptr<____________Widget> upw2(new ____________Widget); // without make func 
      
     auto spw1(std::make_shared<Widget>()); // with make func 
     std::shared_ptr<Widget> spw2(new Widget); // without make func
  2. It’s obvious that this code entails a memory allocation, but it actually performs two. Item 19 explains that every std::shared_ptr points to a control block containing, among other things, the reference count for the pointed-to object. That’s because std::make_shared allocates a single chunk of memory to hold both the Widget object and the control block.
• make function has its limitation:
  1. For example, none of the make functions permit the specification of custom deleters.
  2. the perfect forwarding code uses parentheses, not braces. The bad news is that if you want to construct your pointed-to object using a braced initializer, you must use new directly. Using a make function would require the ability to perfect-forward a braced initializer, but, as Item 30 explains, braced initializers can’t be perfect-forwarded.
  3. As long as std::weak_ptrs refer to a control block (i.e., the weak count is greater than zero), that control block must continue to exist. And as long as a control block exists, the memory containing it must remain allocated. The memory allocated by a std::shared_ptr make function, then, can’t be deallocated until the last std::shared_ptr and the last std::weak_ptr referring to it have been destroyed
• If you can’t use make function, you have to create shared_ptr first, then pass it to function, but a better way is to move it.
  std::shared_ptr<Widget> spw(new Widget, cusDel); 
  processWidget(spw, computePriority()); // correct, but not 
  // optimal; see below 
   
  processWidget(std::move(spw), // both efficient and 
  computePriority()); // exception safe