1.1.9.5 smart pointer Scenario

• Three policy of smart pointer usage:
  1. Owership policy: use smart pointer.
  2. Observer Policy : use raw pointer or reference.
  3. Nullity Policy: Not allow nullptr, prefer to use reference. prefer reference than pointer See effective STL item 7 and 33.
• Observer pointer,observing pointers are pointers which do not keep the pointed object alive raw pointers are bad when used for performing manual memory management, i.e. new and delete. When used purely as a means to achieve reference semantics and pass around non-owning, observing pointers, there is nothing intrinsically dangerous in raw pointers. Just not to dereference a dangling pointer
  observe(subject * s1) 
  // subject is a class 
  //ovserve is function. 
  //just use raw pointer subject, don’t use any smart pointer. 
  //observe don’t have owner policy and life time policy with subject
• Function example1: Inside a function:
  1. If you don’t want to create dynamically or large array, don’t use new. Just use local auto object.
  2. When you have to use new, and this function has Ownership of pointer, means that they have the same life time, use unique_ptr.
  fun(){ 
  Foo fo(); 
  // it make obj directly, 
  //when you don’t need dynamic. 
   
  if(input == "Foo") 
         uniqu_ptr<Foo> up(new Foo() ); 
  //When you need new, use uniqu_ptr 
  }
• Function example2:
  1. As a parameter, pass it to a function. if you don’t want to create dynamicly or large array, don’t use new. Just use reference.
  2. If you have to use new, use uniqu_ptr, and use uniqu_ptr & as argument. Here, You just want to observe sth, no ownership transfer
  3. If you want to transfer ownership to callee from caller, use move.
  Foo *fo = new Foo();  //bad smell here. 
  fun(Foo * p); 
  delete fo; 
   
  fun(Foo &p); //use reference to improve efficiency 
   
  uniqu_ptr<Foo> up(new Foo() ); 
  fun(uniqu_ptr<Foo>& up); //use reference here 
   //to avoid copy, uniqu_ptr can’t copy 
   
  fun(uniqu_ptr<Foo> down);  //prototype 
  fun(std::move(up) );
• Function example3:
  1. As a function return value. if you don’t want to create dynamically or large array, don’t use new. Don’t use reference refer to a local object created inside of fun.
  2. If you have to use New, and you want to transfer Ownership from callee to caller. You should use unique_ptr.
  3. If there is no clear single owner, store and return shared_ptr.(in this example, caller of fun() is single owner, so use unique_ptr)
  Foo* fun(){   //old c style. 
  ........ 
  return new Foo(); 
  } 
   
  unique_ptr<Foo> fun(){  // this is better. 
  ........ 
  return unique_ptr<Foo>(new Foo()) ; 
  }

  below use shared_ptr, because Server is public used, and no single owner.

  shared_ptr<Server> buildNewServer(){  // this is better. 
  return shared_ptr<Foo>(new Foo()) ; 
  } 
   
  shared_ptr<Server> serverForClass1 = buildNewServer(); 
  shared_ptr<Server> serverForClass2  = serverForClass1;
• OOP has four relationships:
  1. Composition: Ownership, same life time, not change in the middle. Car and engine
  2. Aggregation: Ownership, maybe same life time, maybe change in the middle, People and toothbrush(same life time, changeable) Teacher and student( not life time, changeable), Container and pointer(same life time, changeable).
  3. Associate: No Ownership, Includes as a member, different life time, person and father(Not Nullity), person and wife( Nullity)
  4. Dependency: No Ownership, Not Includes as a member, person and friend.
• OOP example1: If it’s mother-son(Composition) relationship, and it’s compiler-given(not dynamic), just use member obj. Pay attention, If Engine has no default ctor, you have to use initialization list in car ctor. initialization list can be used to call base ctor.
  class Car{ 
  Engine eng; // local obj, not use pointer here. 
  Car(int carArg, int engArg): eng(engArg){} 
  }
• OOP example2: If it’s Aggregation relationship, If has same life time, use uniqu_ptr. But if has different life time, just use raw pointer or share_ptr. TootuBrush example, use unique_ptr.
  class Person{ 
  unique_ptr<Brush> unpbrush; 
   
  buyNewBrush(string &name){ 
     unpbrush.reset(new Brush()); 
  // you can’t use unpbrush= new Brush() 
  // unpbrush assignment only support( unique_ptr<T> &&); 
  // use reset, it will make original deleted automatically 
  } 
   
  // don’t need destructor any more. 
  }
• OOP example3: if it’s wife-husband(Association) relationship, If not Nullity, use reference, such as mother, ou need to use initialization list to init mother. If Nullity, such as wife, just use raw pointer. Because no ownership involved, don’t use uniqu_ptr at all.
  class Man{ 
  woman* wife; // can be set to nullptr. 
                 //maybe change in the future, 
                 //may live longer than you. 
   
  woman &mother; //must give a mother in initial list 
  }
• OOP example4: if it’s Dependency, such as friend relationship, Just use member pointer or reference as function parameter.
  class Man{ 
  lendMoney( Man * friend); 
  } 
                                     //or just use it one time. 
  lendMoney(Man * f1); //  don’t need to keep it in a class .
• OOP example5: Suppose Man and Computer is has-a relationship and same life time. Don’t use pointer or reference, just copy from a common computer, and maybe later you can customize your computer, and it will not effect common one. We can copy from commonComputer and init all Worker object. And this time use initialization list can improve efficiency.
  class Worker{ 
  Computer m_desktop; 
  Worker (Computer u): m_desktop(u){} 
  } 
   
  Computer commonComputer; 
  Worker Yan(commonComputer); 
  Worker Gang(commonComputer);
• OOP example6: Change a semantic, unit1 may have a bus, but owner policy tell us that bus can be shared by different unit. and life time policy tell us that bus and unit has separate life time. so here, we should use shared_ptr
  class unit1{ 
  shared_ptr<Bus> busp; 
  }