Lec 15: RAII, Smart Pointers and Building CPP Projects

Code Paths

string EvaluateSalaryAndReturnName(Employee e) {
    if (e.Title() == "CEO" && e.Salary() > 100000) {
        cout << e.First() << " " << e.Last() << " is overpaid" << endl;
    }
    return e.First() + " " + e.Last();
}

Hidden code paths: There are (at least) 23 places where this function can throw exceptions (and thus return early):

• 1 Copy constructor of Employee parameter, may throw.
• 5 Constructor of temp string/ints, may throw.
• 6 Call to Title, Salary, First (2), Last (2), may throw.
• 10 Operators may be user-overloaded, may throw.
• 1 Copy constructor of string for return value, may throw.

And there are 3 exception-free code paths (i.e. normal code paths).

So, in total, at least 26.

Memory Leak Issue

string EvaluateSalaryAndReturnName(int idNumber) {
    Employee* e = new Employee(idNumber);
    if (e->Title() == "CEO" && e->Salary() > 100000) {
        cout << e->First() << " " << e->Last() << " is overpaid" << endl;
    }
    auto result = e->First() + " " + e->Last();
    delete e;
    return result;
}

If any exception is thrown in these segment of code,

if (e->Title() == "CEO" && e->Salary() > 100000) {
    cout << e->First() << " " << e->Last() << " is overpaid" << endl;
}
auto result = e->First() + " " + e->Last();

it will cause memory leak.

More general concern: resources that need to be returned

	Acquire	Return
Heap Memory	new	delete
Files	open	close
Locks	try_lock	unlock
Sockets	socket	close
...	...	...

Exception Safety

There are four levels of exception safety.

• In Google C++ style guide, they follow the first level.
• But in our course, we shall follow the third level - "basic exception guarantee"

RAII

Note: A Better Name For RAII is CADRE - Constructor Acquires,Destructor Releases.

Comparison between Google's guide and RAII:

• Google's guide guarantees that all hidden data paths are forbidden. So we can plainly free all pointers immediately before return.
• RAII guarantees that
• All resources should be acquired in the constructor. All resources should be released in the destructor.
• And no more (so as to prevent double delete)

The Rationale Behind RAII

• There should never be a "half-valid"state of the object. Object useable after its creation.
• The destructor is always called (even with exceptions), so the resource is always freed.

Example: ifstream

The old code (which doesn't comply with RAII):

void printFile() {
    ifstream input;
    input.open("hamlet.txt");

    string line;
    while (getline(input, line)) {
        cout << line << endl;
    }

    input.close();
}

The new code that complies with RAII. i.e.

• open on constructing
• close on destructing

void printFile() {
    ifstream input("hamlet.txt");

    string line;
    while (getline(input, line)) { // might throw exception here!
        cout << line << endl;
    }

    // no close call needed!  
}   // stream destructor,releases access to file

Example: lock_guard

The old code (which doesn't comply with RAII), i.e.

• lock on constructing (lock_guard)
• unlock on destructing (lock_guard)

void cleanDatabase(mutex& databaseLock, map<int, int>& database) {
    databaseLock.lock();
    // other threads will not modify the database
    // modify the database
    // if an exception is thrown, the mutex is never unlocked!
    databaseLock.unlock();
}

The new code:

void cleanDatabase(mutex& databaseLock, map<int, int>& database) {
    lock_guard<mutex> lock(databaseLock);
    // other threads will not modify the database
    // modify the database
    // if an exception is thrown, that's fine!
    // no release call needed
    // lock always unlocked when function exits
}

Also, the implementation of lock_guard is:

template <typename T>
class lock_guard {
public:
    lock_guard(T& lock) : acquired_lock(lock) {
        acquired_lock.lock();
    }

    ~lock_guard() {
        acquired_lock.lock();
    }
private:
    T& acquired_lock;
};

Example: Smart Pointer

std::unique_ptr

• Uniquely owns its resource and deletes it when the object is destroyed.
• Cannot be copied!
• If you have two unique_ptr instances pointing to the same memory, when one of them is destructed and the memory get released, the pointer of the other instance will become invalid.

std::shared_ptr

• Resource can be stored by any number of shared_ptrs.
• Deleted when none of them point to it.