1.2.5 RAII

• Whenever you deal with a resource that needs paired acquire/release function call, encapsulate that resource in an object. Such as: fopen/fclose, lock/unlock, and new/delete.
• When implementing RAII, be conscious of copy construction and assignment. the compiler-generated version probably won’t be correct. If it’s not copyable, use =delete , if it’s copyable, duplicate the resource. You also can use smart_pointer in this scenario too.
• The basic idea of RAII is to represent a resource by a local object, so that the local objectâĂŹs destructor will release the resource. That is to say: To prevent resource leaks, use RAII objects that acquire resources in their constructors and release them in their destructors.
  //C version, 
  File* fp = fopen("/path/to/file"); 
  // throw exception here, then resource leaking 
  fclose(fp); 
   
  //Java version 
  try { 
      File file = new File("/path/to/file"); 
      // throw exception here, go to finally. 
  } finally { 
      file.close(); 
  } 
   
  //c++ version 
  fun{ 
  fstream if("path/to/file") 
  if.getline 
  // you don’t need to if.close(). 
  } 
   
  //c++ smart version. 
  std::unique_ptr<FILE,          // <-- the wrapped raw pointer type: FILE* 
                  int(*)(FILE*)> // <-- the custom deleter type: fclose() prototype 
  myFile( fopen("myfile", "rb"), // <-- resource (FILE*) is returned by fopen() 
          fclose );              // <-- the deleter function: fclose()
• Another good example RAII is unique_ptr. The idea of smart pointer is putting *p into a local pointer-like object, then when it go out scope or unwind-stack when exception is thrown, It will call destructor, then delete p.
• We should consider resource generically, pointer *p pointed to a new object is resource, A handle to a file is a resource to. We wrap handle to a file into ifstream, and wrap pointer *p into smart_pointer
• Just like return value, Exception will skip all the statement below the throw, In C++, It doesn’t support finally statement sometimes. At this time, we need to use RAII.
  Int *p = new int; 
  string a   //a is ok, a will be destructed properly 
                //due to the C++ unwind stack. 
  throw exception. 
  delete p; // this will not run.
• For this problem, you should use smart pointer to declare a auto object. If you use string object, It’s ok. So in previous example, you can use smart pointer, it will help you to avoid memory leakage problem.
  unique_ptr<int> aupr (new int(100); 
  string a   //a is ok, a will be destructed properly 
                //due to the C++ unwind stack. 
  throw exception. 
  // both a and aupr will call their own destructor  function.
• In you ctor, If you use new and new failed and throw a exception, the destructor will not be called. You can use auto_ptr as member data and use init list to initialzie it. see more effective C++ exception chapter.
• Don’t use C FILE* and char [] as string. Use iofile class and string object, because they are exception safe
  1. Any time when you use new, consider if there are c++ container or object.
  2. If not, use smart_pointer.
• Another example is when you make program based on Win API.
  class module { 
  public: 
      explicit module(std::wstring const& name) 
      : handle { ::LoadLibrary(name.c_str()) } {} 
   
      ~module{ 
         ::FreeLibrary(); 
      } 
  private: 
      HMODULE handle; 
  };
• There are three RAII implementation instances in your practical programming:
  1. Use auto member; You have to keep m_str and vc are RAII. In this way, you don’t need to build dtor manually.
     class RAII { 
     private: 
         string m_str; 
         vector<int> vc; 
     };
  2. Use pointer and handle; In this way, You have to use pointer, Maybe you need some customized action in runtime , Use handle is only method to use this resource or any other reason. And this time, you have to write your own dtor.
     class RAII { 
     private: 
         string* m_str; 
         vector<int*> vc; 
     };
  3. Use smart point wrap pointer and handle; When you wrap handle, you can custom this delete behavior. See source code below:
     class RAII { 
     private: 
         unique_ptr<string>  m_str; 
         vector<unique_ptr<int> > vc; 
     };
     class module { 
     public: 
         explicit module(std::wstring const& name) 
         : handle { ::LoadLibrary(name.c_str()) } {} 
     private: 
     using module_handle = std::unique_ptr<void, decltype(&::FreeLibrary)>; 
        module_handle handle; 
     };
• Another question is ownership of resource:
  1. For auto member resource: 1)Same life duration(RAII), 2)exclusive ownship to a single obj, but it’s copyable(A a1 = a2). 3)move with efficiency(A a1 = A() ) . If auto member has it’s own copy and move special function, You don’t need to write any special function in your class. You follow the "Rule of Zero".
  2. For raw pointer and handle: 1) default copy ctor will cause two pointer or handle refer the same resource, It’s absolutely BAD SMELL of code 2) So you have to follow "Rule of five" to build your special member function. 3) After you build five special member function, you get RAII and exclusive ownship to a single object, and copyable and efficient move
     Class RawPointer{ 
     ........... 
     RawPointer(const RawPointer& rhs){ 
     pRes = new Resource( *(rhs.pRes)); 
     } 
      
     RawPointer(RawPointer&& rhs){ 
     pPes = rhs.pRes; 
     rhs.pRes = nullptr; 
     } 
     private: 
     Resource* pRes; 
     }
  3. For uniqu_ptr; 1) Same life(RAII) 2)exclusive ownship but not copyable 3) uniqu_ptr support move operation. You still follow "rule of zero"
  4. Even with uniqu_ptr member, If you follow "rule of zero", that is to say that you don’t provide any customized special member function, then the class is not copyable. But if you build copy ctor by youself, get raw pointer from origin side, and build a new uniqu_ptr member from origin side’s raw pointer, you can implement copyable, and code smell better than raw pointer with "Rule of Five". So in this way, It’s not recommended to use raw pointer in RAII and ownership context.
  5. For shared_ptr; 1) Not a RAII 2) shared ownship, 3) copyable and moveable. When you move a shared_ptr, origin one is set to nullptr and ref count doesn’t increas. You still follow "rule of zero".
• Conclusion, If you consider RAII and ownship at the same time, thing will become complex so I would like to give you some examples to illustrate them.
  1. Prefer to use auto member for most of time! It follow "Rule of Five" and support copyable and movable.
  2. For special demand, for example Car class, people can custom its engine, and buy two at the same time. In this context, you car class should use raw pointer, 1) auto member doesn’t support custom 2) uniqu_ptr doesn’t support copyable. And you have to follow "Rule of Five"
     class Car{ 
     //follow "Rule of Five" 
     Engine *pEn; 
     ~Car(){delete pEn} // assure RAII 
     }
  3. For special context, It doesn’t support object copy: for example 1) Person class in semantic; 2) other perform consideration, Class Bigint [30000];; 3) Other implementation constrain, such as iostream class. Under such context, you can use uniqu_ptr to manage the resource and implement uncopyable.
     class Person{ 
     uniqu_ptr<Resource> pRes; 
     }
  4. For special context, shared resource, you can use shared_ptr. You still can follow "Rule of zero" and resource will be deleted when ref count is 0.
     class Student{ 
     shared_ptr<SchoolBus> pBus 
     }
  5. To know semantic of two smart pointers. Don’t use them just replace raw pointer.