Printable View
Hi,
I wonder if it is required to close an object of ofstream after using it? i.e. similar to FILE in stdio.h of C?
I used to do like this:
without fout.close(). Is it right?Code:ofsteam fout(filename);
fout<<...;
When is it required to call close()? If I try to associate fout with another file, shall I call fout.close() first before call fout.open(newfilename)?
Thanks and regards!
close() will be called when the object is destructed (i.e., when it goes out of scope). You will have to close a file before you can open a new file with the same ofstream object.
(Edit: Well, I don't know if close itself is actually called during destruction -- but the file is closed at that time.)
When using ofstream it is good practice to definitely always stream.close(); after you've finished using it. It's definitely the safer way.
Personally, I prefer not to. I'd rather concentrate on limiting the variable to only the scope that it is needed, and letting RAII handle it. On the surface it might seem less clear what is happening (the file is being closed automatically) but if you use RAII enough then it makes much more sense. And since in general the use of RAII is good practice, you could say that limiting scope and not calling close is better practice than always calling close() explicitly.
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?)
It's not good practice and it's not always safer.Quote:
Originally Posted by execute
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.Quote:
Originally Posted by Elysia
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?Quote:
Originally Posted by execute
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.
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.Quote:
Originally Posted by execute
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#.)Quote:
Originally Posted by execute
Of course it's not.Quote:
Originally Posted by execute
...Unless you are using a smart pointer.Quote:
You learn that when you create something new, you learn to delete it.
That's C. Not C++.Quote:
You use malloc you learn to free.
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.Quote:
It is good practice and it frees up memory faster than letting it go out of scope.
Don't compare C++ to C# and Java.Quote:
Maybe if you're future is in C# or java, then you're right it's bad practice.
C++ has RAII and you can be sure it beats C#, Java AND the manual C way.
So is this how you write your C++ code?Quote:
Of course it's good practice. You learn that when you create something new, you learn to delete it.
Code:void foo()
{
std::auto_ptr<MyClass> ap(new MyClass());
// use ap
ap.reset(NULL); // force the destruction of the object in the smart pointer
}
Actually in Java, since there are no destructors you have to explicitly close your file streams.Quote:
Maybe if you're future is in C# or java, then you're right it's bad practice.
EDIT: laserlight and Elysia beat me to it.
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.)
You are missing the whole point of RAII. Learning to manually match resource allocation with deallocation is learning it "the hard way."Quote:
Originally Posted by execute
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.
To elaborate, the using() statement is an exception-safe manual call to close, that looks like this:Quote:
Originally Posted by anon
and is basically:Code:using (var v = new SomeClass())
{
// code
}
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).Code:var v = new SomeClass();
try
{
// code
}
finally
{
v.Dispose();
}
Furthermore, you have to do this on so many objects, I often wonder if the garbage collection acutally helps. Whereas you might have:
...which in C++ is:Code:using(Lock a = first_mutex.Lock())
{
using(Lock b = second_mutex.Lock())
{
using(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.)Code:Lock a = first_mutex.lock();
Lock b = second_mutex.lock();
Lock c = third_mutex.lock();
// do something.
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.