destructor and file descriptors

[Digital Puer]

I fixed a bug today that went against my intuition. I am on Linux.
I had a class that fopen'ed some files. When I called delete
on these objects, I expected that the files would be closed
automatically, just as when an application terminates, but
evidently this is not the case. I guess I have to fclose the files
in the destructor.

Is this a correct assessment?

[Daniel T.]

"Digital Puer" <di**********@h otmail.comwrote :

I fixed a bug today that went against my intuition. I am on Linux.
I had a class that fopen'ed some files. When I called delete
on these objects, I expected that the files would be closed
automatically, just as when an application terminates, but
evidently this is not the case. I guess I have to fclose the files
in the destructor.

Is this a correct assessment?

Yes. If you use fstream instead, they will automatically close.

[Marcus Kwok]

Digital Puer <di**********@h otmail.comwrote :

I fixed a bug today that went against my intuition. I am on Linux.
I had a class that fopen'ed some files. When I called delete
on these objects, I expected that the files would be closed
automatically, just as when an application terminates, but
evidently this is not the case. I guess I have to fclose the files
in the destructor.

Is this a correct assessment?

I would say yes. However, if you used std::fstream objects instead of
FILE*, then the fstream destructors would handle closing the files, so
you wouldn't need to manually close them in your destructor.

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Roland Pibinger]

On 22 Jan 2007 18:29:26 -0800, "Digital Puer" wrote:

>I fixed a bug today that went against my intuition. I am on Linux.
I had a class that fopen'ed some files. When I called delete
on these objects, I expected that the files would be closed
automaticall y, just as when an application terminates, but
evidently this is not the case. I guess I have to fclose the files
in the destructor.

Is this a correct assessment?

Merely calling fclose() in the destructor is not the right solution
when the file has been opened for writing. You need to check the
return value of fclose() and conduct appropriate action when fclose()
fails. Therefore the place for 'successful' fclose() is not the
destructor but another member function. In the destructor you can only
perform rollback, undo or cleanup activities which may include a
fclose() that terminates the unsuccessful file operation. The
situation is diffenent when the file has been opened for read only. In
that case you can put fclose() in the destructor only and ignore the
return value.

Best wishes,
Roland Pibinger

[Daniel T.]

rp*****@yahoo.c om (Roland Pibinger) wrote:

Merely calling fclose() in the destructor is not the right solution
when the file has been opened for writing. You need to check the
return value of fclose() and conduct appropriate action when
fclose() fails.

Could you post some more details on this one? What kind of actions is
appropriate when fclose fails? I ask because basic_fstream's close
function returns void. Presumably, it does the appropriate action you
speak of?

[Roland Pibinger]

On Tue, 23 Jan 2007 23:14:43 GMT, "Daniel T." wrote:

>rpbg123@...c om (Roland Pibinger) wrote:

>Merely calling fclose() in the destructor is not the right solution
when the file has been opened for writing. You need to check the
return value of fclose() and conduct appropriate action when
fclose() fails.

Could you post some more details on this one? What kind of actions is
appropriate when fclose fails?

This is more a design than an implementation question. One common
setting is that the whole file is read into memory, some changes are
made and the contents is written back to disk by overwriting the
original file. When fwrite() or fclose() fails the original file is
already destroyed and the new file is corrupt (half written).
One solution is that the original file is never overwritten, i.e.
never opened for write. This means that you write the contents to a
temporary file, close the temporary file (check the return value),
delete the original file and rename the temporary file to the original
file. Error-/failure-handling in that case just means that the
partially written temporary file is closed and deleted (the original
file remians unchanged). This kind of error-/failure-handling can also
be done in the destructor when the file has not been closed before
(the destructor performs only error-/failure-handling).

>I ask because basic_fstream's close
function returns void. Presumably, it does the appropriate action you
speak of?

AFAIK, fstream() has functions like good(), bad(), fail(), ... to let
the user ckeck the stream state.

Best wishes,
Roland Pibinger