Is cleaning your code not required anymore in C++?

Question

I was reading an article that stated due to something called RAII, you no longer needed to cleanup your code.

What prompted this research was I am currently coding something that requires cleanup before exiting the function.

For example, I have created a file, and mapped a view of a file.

Normally, I'd just use goto or do {break;} while(false); to exit. However, is it true this is no longer necessary with C++11?

I.e. no more

if( fail ) {
        UnmapViewOfFile(lpMapView);
        CloseHandle(hFileMap);
        CloseHandle(hFile);
}

every few lines of code?

Does the compiler automatically wrap this up once the function exits? It just seems hard to believe that it actually cleans up function calls like the article said it did. (I may have misinterpreted it somehow.) What seems more likely is that it just cleans up created class libraries by calling their deconstructor from the C++ library.

EDIT: The article - from Wikipedia:

It doesn't necessarily state that it cleans up these function calls, but it does imply it does for C++ library function objects (such as FILE * , fopen, etc objects)

Does it work for WinAPI too?

Answer 1

Cleanup is still necessary, but due to the possibility of exceptions the code should not do cleanup simply by executing cleanup operations at the end of a function. That end may never be reached! Instead,

    Do cleanup in destructors.

In C++11 it is particularly easy to any kind of cleanup in a destructor without defining a custom class, since it's now much easier to define a scope guard class. Scope guards were invented by Petru Marginean, who with Andrei Alexandrescu published an article about it in DDJ. But that original C++03 implementation was pretty complex.

In C++11, a bare bones scope guard class:

class Scope_guard
    : public Non_copyable
{
private:
    function<void()>    f_;

public:
    void cancel() { f_ = []{}; }

    ~Scope_guard()
    { f_(); }

    Scope_guard( function<void()> f )
        : f_( move( f ) )
    {}
};

where Non_copyable provides move assignment and move construction, as well as default construction, but makes copy assignment and copy construction private.

Now right after successfully acquiring some resource you can declare a Scope_guard object that will guaranteed clean up at the end of the scope, even in the face of exceptions or other early returns, like

Scope_guard unmapping( [&](){ UnmapViewOfFile(lpMapView); } );

---

Addendum:
I should better also mention the standard library smart pointers shared_ptr and unique_ptr, which take care of pointer ownership, calling a deleter when the number of owners goes to 0. As the names imply they implement respectively shared and unique ownership. Both of them can take a custom deleter as argument, but only shared_ptr supports calling the custom deleter with the original pointer value when the smart pointer is copied/moved to base class pointer.

Also, I should better also mention the standard library container classes such as in particular vector, which provides a dynamic size copyable array, with automatic memory management, and string, which provides much the same for the particular case of array of char uses to represent a string. These classes free you from having to deal directly with new and delete, and get those details right.

So in summary,

• use standard library and/or 3^rd party containers when you can,

• otherwise use standard library and/or 3^rd party smart pointers,

• and if even that doesn't cut it for your cleanup needs, define custom classes that do cleanup in their destructors.

Answer 2

It does NOT cleanup `FILE*.

If you open a file, you must close it. I think you may have misread the article slightly.

For example:

class RAII
{
    private:
        char* SomeResource;

    public:
        RAII() : SomeResource(new char[1024]) {} //allocated 1024 bytes.
        ~RAII() {delete[] SomeResource;} //cleaned up allocation.

            RAII(const RAII& other) = delete;
            RAII(RAII&& other) = delete;
            RAII& operator = (RAII &other) = delete;
};

The reason it is an RAII class is because all resources are allocated in the constructor or allocator functions. The same resource is automatically cleaned up when the class is destroyed because the destructor does that.

So creating an instance:

void NewInstance()
{
    RAII instance; //creates an instance of RAII which allocates 1024 bytes on the heap.
} //instance is destroyed as soon as this function exists and thus the allocation is cleaned up
  //automatically by the instance destructor.

See the following also:

void Break_RAII_And_Leak()
{
    RAII* instance = new RAII(); //breaks RAII because instance is leaked when this function exits.
}

void Not_RAII_And_Safe()
{
    RAII* instance = new RAII(); //fine..
    delete instance;             //fine..
    //however, you've done the deleting and cleaning up yourself / manually.
    //that defeats the purpose of RAII.
}

Now take for example the following class:

class RAII_WITH_EXCEPTIONS
{
    private:
        char* SomeResource;

    public:
        RAII_WITH_EXCEPTIONS() : SomeResource(new char[1024]) {} //allocated 1024 bytes.

        void ThrowException() {throw std::runtime_error("Error.");}

        ~RAII_WITH_EXCEPTIONS() {delete[] SomeResource;} //cleaned up allocation.

            RAII_WITH_EXCEPTIONS(const RAII_WITH_EXCEPTIONS& other) = delete;
            RAII_WITH_EXCEPTIONS(RAII_WITH_EXCEPTIONS&& other) = delete;
            RAII_WITH_EXCEPTIONS& operator = (RAII_WITH_EXCEPTIONS &other) = delete;
};

and the following functions:

void RAII_Handle_Exception()
{
    RAII_WITH_EXCEPTIONS RAII; //create an instance.
    RAII.ThrowException();     //throw an exception.

    //Event though an exception was thrown above,
    //RAII's destructor is still called
    //and the allocation is automatically cleaned up.
}

void RAII_Leak()
{
    RAII_WITH_EXCEPTIONS* RAII = new RAII_WITH_EXCEPTIONS();
    RAII->ThrowException();

    //Bad because not only is the destructor not called, it also leaks the RAII instance.
}

void RAII_Leak_Manually()
{
    RAII_WITH_EXCEPTIONS* RAII = new RAII_WITH_EXCEPTIONS();
    RAII->ThrowException();
    delete RAII;

    //Bad because you manually created a new instance, it throws and delete is never called.
    //If delete was called, it'd have been safe but you've still manually allocated
    //and defeated the purpose of RAII.
}

fstream always did this. When you create an fstream instance on the stack, it opens a file. when the calling function exists, the fstream is automatically closed.

The same is NOT true for FILE* because FILE* is NOT a class and does NOT have a destructor. Thus you must close the FILE* yourself!

EDIT: As pointed out in the comments below, there was a fundamental problem with the code above. It is missing a copy constructor, a move constructor and assignment operator.

Without these, trying to copy the class would create a shallow copy of its inner resource (the pointer). When the class is destructed, it would have called delete on the pointer twice! The code was edited to disallow copying and moving.

For a class to conform with the RAII concept, it must follow the rule for three: What is the copy-and-swap idiom?

If you do not want to add copying or moving, you can simply use delete as shown above or make the respective functions private.

Answer 3

I really liked the explanation of RAII in The C++ Programming Language, Fourth Edition

Specifically, sections 3.2.1.2, 5.2 and 13.3 explain how it works for managing leaks in the general context, but also the role of RAII in properly structuring your code with exceptions.

The two main reasons for using RAII are:

1. Reducing the use of naked pointers that are prone to causing leaks.
2. Reducing leaks in the cases of exception handling.

RAII works on the concept that each constructor should secure one and only one resource. Destructors are guaranteed to be called if a constructor completes successfully (ie. in the case of stack unwinding due to an exception being thrown). Therefore, if you have 3 types of resources to acquire, you should have one class per type of resource (class A, B, C) and a fourth aggregate type (class D) that acquires the other 3 resources (via A, B & C's constructors) in D's constructor initialization list.

So, if resource 1 (class A) succeeded in being acquired, but 2 (class B) failed and threw, resource 3 (class C) would not be called. Because resource 1 (class A)'s constructor had completed, it's destructor is guaranteed to be called. However, none of the other destructors (B, C or D) will be called.

Answer 4

The WIN32 API is a C API - you still have to do your own clean up. However nothing stops you from writing C++ RAII wrappers for the WIN32 API.

Example without RAII:

void foo
{
   HANDLE h = CreateFile(_T("C:\\File.txt"), FILE_READ_DATA, FILE_SHARE_READ,
NULL, OPEN_ALWAYS, 0, NULL);
   if ( h != INVALID_HANDLE_VALUE )
   {
     CloseHandle(h);
   }
}

And with RAII:

class smart_handle
{
   public:
      explicit smart_handle(HANDLE h) : m_H(h) {} 
      ~smart_handle() {  if (h != INVALID_HANDLE_VALUE) CloseHandle(m_H); }
   private:
       HANDLE m_H;
   // this is a basic example, could be implemented much more elegantly! (Maybe a template param for "valid" handle values since sometimes 0 or -1 / INVALID_HANDLE_VALUE is used, implement proper copying/moving etc or use std::unique_ptr/std::shared_ptr with a custom deleter as mentioned in the comments below).
};

void foo
{
   smart_handle h(CreateFile(_T("C:\\File.txt"), FILE_READ_DATA, FILE_SHARE_READ,
NULL, OPEN_ALWAYS, 0, NULL));
   // Destructor of smart_handle class would call CloseHandle if h was not NULL
}

RAII can be used in C++98 or C++11.

Answer 5

No!

RAII is not about leaving clean-up aside, but doing it automatically. The clean-up can be done in a destructor call.

A pattern could be:

void f() {
    ResourceHandler handler(make_resource());
    ...
}

Where the ResourceHandler is destructed (and does the clean-up) at the end of the scope or if an exception is thrown.

Answer 6

C++ standard surely says nothing about usage of windows API functions like UnmapViewOfFile or CloseHandle. RAII is a programming idiom, you can use it or not, and its a lot older than C++11.

One of the reasons why RAII is recomended is that it makes life easier when working with exceptions. Destructors will always safely release any resources - mostly memory, but also handles. For memory your have classes in standard library, like unique_ptr and shared_ptr, but also vector and lots of other. For handles like those from WinAPI, you must write your own, like:

class handle_ptr {
public:
  handle_ptr() {
    // aquire handle
  }
  ~handle_ptr() {
    // release
  }
}

Answer 7

As @zero928 said in the comment, RAII is a way of thinking. There is no magic that cleans up instances for you.

With RAII, you can use the object lifecycle of a wrapper to regulate the lifecycle of legacy types such as you describe. The shared_ptr<> template coupled with an explicit "free" function can be used as such a wrapper.

Answer 8

As far as I know C++11 won't care of cleanup unless you use elements which would do. For example you could put this cleaning code into the destructor of a class and create an instance of it by creating a smart-pointer. Smart-pointers delete themselves when they are not longer used or shared. If you make a unique-pointer and this gets deleted, because it runs out of scope then it automatically calls delete itself, hence your destructor is called and you don't need to delete/destroy/clean by yourself.

See http://www.cplusplus.com/reference/memory/unique_ptr/

This is just what C++11 has new for automatically cleaning. Of course an usual class instance running out of scope calls its destructor, too.