RAII and Smart Pointers - Resource Management in C++

RAII stands for Resource Acquisition Is Initialization.

What is it and why it is needed?
We used different resource in out software such as file streams, network pipes, database connections and even locks are considered as resources.
The standardized procedure of using a resource is to acquire the resource, use it and then release it. Holding onto resources is bad practice and starves other processes for resources slowing down the entire system in multicore systems.

OK, what's the big deal?
So we want to open a file, write some stuff to it and then close it.
We just do.

file.open();
file.write("test");
file.close();

Caution here. If it's a trivial task where you don't have anything in between opening and closing the file (or any other resource) this seems fine but this is often not the case. You have many other things that you do between you opening the file and closing the file. Chances are these operations might fail, or worse throw.
In such case the programmers must ensure that they release their resources promptly even when throwing is expected. Java users can example use 'finally clause' after the try-catch blocks but in high performance systems handling exceptions is usually disregarded and there's nothing the programmer can do but to ensure that he frees his resources and continue other work.
Otherwise this would lead to memory leaks. Further what if a lock is not freed in such a situation>
This would surely cause the program to stall because of a deadlock.

Example usage of RAII idiom

//  Private copy constructor and copy assignment ensure classes derived 
//  from class NonCopyable cannot be copied.
class NonCopyable 
{
   NonCopyable (NonCopyable const &); // private copy constructor
   NonCopyable & operator = (NonCopyable const &); // private assignment operator
};
template <class T>
class AutoDelete : NonCopyable
{
  public:
    AutoDelete (T * p = 0) : ptr_(p) {}
    ~AutoDelete () throw() { delete ptr_; } 
  private:
    T *ptr_;
};
 
class ScopedLock : NonCopyable// Scoped Lock idiom
{
  public:
    ScopedLock (Lock & l) : lock_(l) { lock_.acquire(); }
    ~ScopedLock () throw () { lock_.release(); } 
  private:
    Lock& lock_;
};
 
void foo ()
{
  X * p = new X;
  AutoDelete<X> safe_del(p); // Memory will not leak
  p = 0;
  // Although, above assignment "p = 0" is not necessary
  // as we would not have a dangling pointer in this example. 
  // It is a good programming practice.
 
  if (...)
    if (...)
      return; 
 
  // No need to call delete here.
  // Destructor of safe_del will delete memory
}
void X::bar()
{
  ScopedLock safe_lock(l); // Lock will be released certainly
  if (...)
    if (...)
      throw "ERROR"; 
  // No need to call release here.
  // Destructor of safe_lock will release the lock
}

Things to note:
1. The class should be non-copyable? Why? Because most of the time resources classes like file, database, network and locks have no copy semantics.
2. Destructors might encounter throws while releasing resources and the destructors itself should handle this because destructors don't return and can't propagate anything outside.

OK. All Good. So I go ahead and do this.

void setLog(const Foo & foo, const Bar & bar) {
    File* file = new File("/path/to/file", File::append);
    foo.setLogFile(file);
    bar.setLogFile(file);
}

This will crash because foo and bar will have invalid  references at the end of the function.
Further, it is important to note that these instances are almost always local variables (they live in the stack or within another object as an attribute); placing them in the heap (thus making them dynamic) makes no sense and could defeat the whole idea behind RAII. 

What can we do ti alleviate these issues? shared_ptr to the rescue.

void setLog(const Foo & foo, const Bar & bar) { 
    shared_ptr<File> file = new File("/path/to/file", File::append); // reference count 1
    foo.setLogFile(file); // reference count 2
    bar.setLogFile(file); // reference count 3
} // reference count 2

Now the shared_ptr will have a reference count of 2 when it exits the function and will not be deleted until the foo and bar objects are destroyed/or until they don't have an references to the *file.

Why is JAVA not into RAII?
Garbage collector.
Having GC means that the destruction of objects is unpredictable. This means that the resources might be tied up and we can't really say when it's going to be released.

By using RAII-modeled classes, the developer need not care about explicitly releasing the acquired resources: they will be freed automatically when the instance that manages them goes out of scope.