Thread: ofstream close

When using ofstream it is good practice to definitely always stream.close(); after you've finished using it. It's definitely the safer way.

I thought you'd call close() only if you indeed for some reason wanted to close the filestream earlier than it goes out of scope.

Calling it yourself is not definitely this much safer (except perhaps if your program crashes between the point where the filestream could be closed and where it goes out of scope - but then you should fix the program so it doesn't crash, and those points tend to be quite close by anyway).

Filestreams are an example of RAII which is an important principle in C++: objects should automatically clean up after themselves. This is how you should also design your own classes and it means that you also need to trust that clean-up happens automatically. (You wouldn't also happen to call vector.clear() before it goes out of scope, just to be safe?)

Originally Posted by execute

When using ofstream it is good practice to definitely always stream.close(); after you've finished using it. It's definitely the safer way.

It's not good practice and it's not always safer.
Whether or not to do it is up to the programmer.
So it's not bad practice, but it isn't exactly "good" practice either.

Originally Posted by Elysia

It's not good practice and it's not always safer.
Whether or not to do it is up to the programmer.
So it's not bad practice, but it isn't exactly "good" practice either.

Of course it's good practice. You learn that when you create something new, you learn to delete it. You use malloc you learn to free. It is good practice and it frees up memory faster than letting it go out of scope. Maybe if you're future is in C# or java, then you're right it's bad practice.

Originally Posted by execute

Of course it's good practice. You learn that when you create something new, you learn to delete it. You use malloc you learn to free.

Bad analogy: if you use malloc, you should indeed learn to free. But as in anon's analogy, if you learn to use a std::vector, do you also learn to use the clear() member function even when the container is about to be destroyed by going out of scope?

The RAII idiom extends on this good practice of learning to release the resources that you allocate by making the release automatic upon the destruction of the associated object. Consequently, it is actually another way to "learn that when you create something new, you learn to delete it", but even better because you cannot forget to do so.

Originally Posted by execute

It is good practice and it frees up memory faster than letting it go out of scope.

That would be true if the object lives in a scope that is larger than necessary. But as Daved pointed out, if it lives in the smallest scope necessary, then it will be destroyed right on time, releasing the resource as it is destroyed.

Originally Posted by execute

Maybe if you're future is in C# or java, then you're right it's bad practice.

Ironically, that is the opposite: since C# and Java lack deterministic destruction, one should explicitly release such resources instead of relying on the garbage collector. (EDIT: But then I recall a discussion here about C# and/or .NET and some form of deterministic destruction, but I am afraid that I am not qualified to comment on such specifics with respect to C#.)

Originally Posted by execute

Of course it's good practice.

Of course it's not.

You learn that when you create something new, you learn to delete it.

...Unless you are using a smart pointer.

You use malloc you learn to free.

That's C. Not C++.

It is good practice and it frees up memory faster than letting it go out of scope.

Clutters up the code with possibly lots of close calls instead of just letting it go out of scope. Furthermore, not using the destructors usually results in bugs because you forgot to add a close call if certain conditions happens.

Maybe if you're future is in C# or java, then you're right it's bad practice.

Don't compare C++ to C# and Java.
C++ has RAII and you can be sure it beats C#, Java AND the manual C way.

I have sniffed some C# and while destructor calls don't seem to be guaranteed, they have something called a using statement, so if the file object is IDisposable you'd put the file operations in a using block. (It would still be possible to have live references to disposed IDisposables? And it would be possible to forget to use the using block. Which makes me like C++'s destructors.)

Originally Posted by execute

Of course it's good practice. You learn that when you create something new, you learn to delete it. You use malloc you learn to free. It is good practice and it frees up memory faster than letting it go out of scope. Maybe if you're future is in C# or java, then you're right it's bad practice.

You are missing the whole point of RAII. Learning to manually match resource allocation with deallocation is learning it "the hard way."

Designs which require explicit resource deallocation are error prone. Not only because you may forget to release a resource, but because exceptions may cause code paths to exist that you did not anticipate. Proper use of RAII completely eliminates both problems.

We are trying to take steps forward, not backward.

Originally Posted by anon

I have sniffed some C# and while destructor calls don't seem to be guaranteed, they have something called a using statement, so if the file object is IDisposable you'd put the file operations in a using block. (It would still be possible to have live references to disposed IDisposables? And it would be possible to forget to use the using block. Which makes me like C++'s destructors.)

To elaborate, the using() statement is an exception-safe manual call to close, that looks like this:

Code:

using (var v = new SomeClass())
{
    // code
}

and is basically:

Code:

var v = new SomeClass();
try
{
    // code
}
finally
{
    v.Dispose();
}

In my opinion, it is a sad mixing of language and standard library -- the object in the using() must implement the IDisposable interface, so as .Dispose() can be called. Worse, if you have a simple function that just has three objects in it, you're suddly three scopes and tabs deep - generally for a total of 5 * 4 = 20 spaces. (+2 tabs for class & function).
Furthermore, you have to do this on so many objects, I often wonder if the garbage collection acutally helps. Whereas you might have:

Code:

using(Lock a = first_mutex.Lock())
{
    using(Lock b = second_mutex.Lock())
    {
        using(Lock c = third_mutex.Lock())
        {
            // do something.
        }
    }
}

...which in C++ is:

Code:

Lock a = first_mutex.lock();
Lock b = second_mutex.lock();
Lock c = third_mutex.lock();

// do something.

Which is easier to read, write, and maintain? (And, the C++ will likely free up more resources faster, as the C# one still leaves memory allocated until the GC gets it.)

In short: Don't underestimate the power of RAII. It's an immensely powerful C++ idiom, and when used correctly, it can make quite elegant code. Don't write C code in C++. Write C++, and let RAII take care of you.