A simple (and perhaps overused) example of RAII is a File class. Without RAII, the code might look something like this:
File file("/path/to/file");
// Do stuff with file
file.close();
In other words, we must make sure that we close the file once we've finished with it. This has two drawbacks - firstly, wherever we use File, we will have to called File::close() - if we forget to do this, we're holding onto the file longer than we need to. The second problem is what if an exception is thrown before we close the file?
Java solves the second problem using a finally clause:
try {
File file = new File("/path/to/file");
// Do stuff with file
} finally {
file.close();
}
or since Java 7, a try-with-resource statement:
try (File file = new File("/path/to/file")) {
// Do stuff with file
}
C++ solves both problems using RAII - that is, closing the file in the destructor of File. So long as the File object is destroyed at the right time (which it should be anyway), closing the file is taken care of for us. So, our code now looks something like:
File file("/path/to/file");
// Do stuff with file
// No need to close it - destructor will do that for us
This cannot be done in Java since there's no guarantee when the object will be destroyed, so we cannot guarantee when a resource such as file will be freed.
Onto smart pointers - a lot of the time, we just create objects on the stack. For instance (and stealing an example from another answer):
void foo() {
std::string str;
// Do cool things to or using str
}
This works fine - but what if we want to return str? We could write this:
std::string foo() {
std::string str;
// Do cool things to or using str
return str;
}
So, what's wrong with that? Well, the return type is std::string - so it means we're returning by value. This means that we copy str and actually return the copy. This can be expensive, and we might want to avoid the cost of copying it. Therefore, we might come up with idea of returning by reference or by pointer.
std::string* foo() {
std::string str;
// Do cool things to or using str
return &str;
}
Unfortunately, this code doesn't work. We're returning a pointer to str - but str was created on the stack, so we be deleted once we exit foo(). In other words, by the time the caller gets the pointer, it's useless (and arguably worse than useless since using it could cause all sorts of funky errors)
So, what's the solution? We could create str on the heap using new - that way, when foo() is completed, str won't be destroyed.
std::string* foo() {
std::string* str = new std::string();
// Do cool things to or using str
return str;
}
Of course, this solution isn't perfect either. The reason is that we've created str, but we never delete it. This might not be a problem in a very small program, but in general, we want to make sure we delete it. We could just say that the caller must delete the object once he's finished with it. The downside is that the caller has to manage memory, which adds extra complexity, and might get it wrong, leading to a memory leak i.e. not deleting object even though it is no longer required.
This is where smart pointers come in. The following example uses shared_ptr - I suggest you look at the different types of smart pointers to learn what you actually want to use.
shared_ptr<std::string> foo() {
shared_ptr<std::string> str = new std::string();
// Do cool things to or using str
return str;
}
Now, shared_ptr will count the number of references to str. For instance
shared_ptr<std::string> str = foo();
shared_ptr<std::string> str2 = str;
Now there are two references to the same string. Once there are no remaining references to str, it will be deleted. As such, you no longer have to worry about deleting it yourself.
Quick edit: as some of the comments have pointed out, this example isn't perfect for (at least!) two reasons. Firstly, due to the implementation of strings, copying a string tends to be inexpensive. Secondly, due to what's known as named return value optimisation, returning by value may not be expensive since the compiler can do some cleverness to speed things up.
So, let's try a different example using our File class.
Let's say we want to use a file as a log. This means we want to open our file in append only mode:
File file("/path/to/file", File::append);
// The exact semantics of this aren't really important,
// just that we've got a file to be used as a log
Now, let's set our file as the log for a couple of other objects:
void setLog(const Foo & foo, const Bar & bar) {
File file("/path/to/file", File::append);
foo.setLogFile(file);
bar.setLogFile(file);
}
Unfortunately, this example ends horribly - file will be closed as soon as this method ends, meaning that foo and bar now have an invalid log file. We could construct file on the heap, and pass a pointer to file to both foo and bar:
void setLog(const Foo & foo, const Bar & bar) {
File* file = new File("/path/to/file", File::append);
foo.setLogFile(file);
bar.setLogFile(file);
}
But then who is responsible for deleting file? If neither delete file, then we have both a memory and resource leak. We don't know whether foo or bar will finish with the file first, so we can't expect either to delete the file themselves. For instance, if foo deletes the file before bar has finished with it, bar now has an invalid pointer.
So, as you may have guessed, we could use smart pointers to help us out.
void setLog(const Foo & foo, const Bar & bar) {
shared_ptr<File> file = new File("/path/to/file", File::append);
foo.setLogFile(file);
bar.setLogFile(file);
}
Now, nobody needs to worry about deleting file - once both foo and bar have finished and no longer have any references to file (probably due to foo and bar being destroyed), file will automatically be deleted.
