C++ and Qt: is this a memory leak? (and general questions)

Question

I've mostly used C for programming in the last 2 years (previously some Java) and have decided to learn C++, using Qt Creator and the Qt libraries.

My question is whether the following code introduces a memory leak:

    // filename is a QStringListIterator
    // dir is a QDir
    while (filename.hasNext()) {
            QString came_from_file(dir.filePath(filename.next()));
            QFile file(came_from_file);
            file.open(QFile::ReadOnly);
            file.readLine();
            while (!file.atEnd()) {
                    QString line(file.readLine());
                    do_something_with_stuff(line, came_from_file);
            }
    }

Specifically, I'm not sure what happens to the generated dir.filePath(filename.next()) QString. Is it referenced into came_from_file or is its pointer lost once it is copied? Is it "copied" (I assume it never is, until changed, due to the Copy-On-Write nature of Qt containers)? Should I write this differently, like QString match = dir.file... ? To my understanding, this should be equal.

It also says in the Qt docs that QFile is going to close() the file if necessary in the destructor. Does the destructor get called? The variable does go "out of scope", but I'm still not sure if this is a case of so-called RAII.

How would I make file point to a different file?

If I pass variables like this to functions (I assume this is by reference, as the function do_something... is defined this way), and then they go out of scope, but are insterted into a QHash/QMap/QSet by the function, what happens? Do they get removed and the containers go crazy, or is there some fancy little scheme like ref. counting behind it all? Or are the values simply copied?

I realise similiar questions have been asked before, but I can't seem to figure it out in this example by reading them, as they seem to be different cases.

If there's something wrong with the code or my understanding, please correct me. :)

Thanks, Nanthiel

Answer 1

Specifically, I'm not sure what happens to the generated dir.filePath(filename.next()) QString.

came_from_file is a copy (unless RVO kicks in) of the return value of QDir::filePath , which in turn is a temporary object that is automatically cleaned up. There is no need to assign it to a variable.

Does the destructor get called? The variable does go "out of scope"

When an object goes out of scope, its destructor will be called, unless you use unsafe constructs like longjmp .

How would I make file point to a different file?

I can't find a clean way to do this in the Qt docs for QFile . I suggest you just declare a new QFile for the other file. One possibility to do that, and maintain control over the number of open files, is to use scopes:

{
    QFile file(some_path);
    // do stuff to file
}   // end of file's scope, so it will be closed

{
    QFile file(other_path);
}   // again, end of scope

OTOH, you might want to explicitly close the QFile so that you can check its state after flush/close.

Answer 2

When the code you posted leaves scope, the deconstructors are called on the objects, and everything is cleaned up. Generally speaking, in C++ , the only time you have to worry about memory leaks is when you use the new keyword, or some function that returns a pointer for a system allocated object (like device context's on windows), in which case you'd have to use the appropriate system clean up call.

In the case of functions , all arguments are by value unless specified as references or pointers. References are used as function arguments most often to prevent the performance hit from having to copy a large object into the function. Most of the time these references are const to prevent you from modifying the values of the data passed in. A Reference in C++ is very similar to a pointer, without having the messy pointer syntax.

void foo(bar b); // by value

void foo(const bar& b); // by const ref

void foo(bar& b); // by ref, a mutable bar object, where this function performs some action on the bar object you passed in, and the results of the action will be visible on the original bar object.