-1

I have looked into below question, where I understood that I don't have to close ifstream since the the file handler is closed automatically when exits from the scope. [ defenitely there is no memory leak] [Do I need to manually close an ifstream?1

But in the below code, the file handler is a global variable. So if we dont close the file handler manually it will cause memory leak I think. Is that assumption corruct or the file handler will be automatically handled by c++ ?

#include <iostream>
#include <fstream>
#include <sstream>
#include <unistd.h>

using namespace::std;

ifstream config_file;
stringstream cmd;

int test() {
    config_file.open("config.file");
    cmd << config_file.rdbuf();
    string tmp = cmd.str();
    cout << " config buffer is " << tmp << "\n" <<endl; 
}

int main () {
    test();
    while (1) {
        test();
        sleep(1);
    }
}

Interestingly, cppcheck also didn't report a memory leak in this file.

cppcheck file.cpp 
//no error logs. 

Can someone please confirm that there is memory leak or not in the above code?

AKV
  • 425
  • 7
  • 20
  • You should be able to see this for yourself using a tool such as Process Explorer on Windows, or Top on Linux. Use of sch tools is essential to the longevity of your career. – Christopher Pisz Aug 28 '18 at 15:11
  • If any leak was to happen it would probably by file handle leak not memory leak :) Neither happens anyway, as ifstream automatically closes on destruction. – paler123 Aug 28 '18 at 15:14
  • The file is closed and the resource is freed at program exit when the statics are all destroyed. There is no leak. If you want the file closed and the object's resources released sooner, change the object's scope. – user4581301 Aug 28 '18 at 15:26
  • Thanks Christopher Pisz, but first I wanted to check how the c++ standard handles such a case. As others pointed out there should be no memory leak. I will also try to validate by top as a general test procedure. Besides, if the memory leak was guaranteed to happen, there is no point in testing with top. – AKV Aug 28 '18 at 18:04

3 Answers3

4

No. fstream is an RAII object, it does close automatically at the end of the scope. Which means it is eventually closed for you in any way.

You can, however, close it manually by explicitly calling close or simply nest it in scope using curly-braces {}.

Another situation arises, if you want to check, if the closing of the file succeeded. Than you also have to call it manually. This is useful if you want to guarantee a point in the code where the file is complitly written.

Also make sure to check out cppreference for further information.

The linux man-page for close states the following, which is also interesting to read

Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.

A successful close does not guarantee that the data has been successfully saved to disk, as the kernel defers writes. It is not common for a filesystem to flush the buffers when the stream is closed. If you need to be sure that the data is physically stored use fsync(2). (It will depend on the disk hardware at this point.)

It is probably unwise to close file descriptors while they may be in use by system calls in other threads in the same process. Since a file descriptor may be reused, there are some obscure race conditions that may cause unintended side effects.

I am not sure about the situation of flush on windows. Maybe someone can add this information.

Further close() guarantees to throw an exception on failure which you can catch and handle.

Community
  • 1
  • 1
2

No. The destructor of std::ifstream closes the stream implicitly. The scope does not matter in this case - the destructor will eventually be called.

Fureeish
  • 12,533
  • 4
  • 32
  • 62
1

The file stream's default destructor closes the file regardless.

Matthew
  • 115
  • 10