destructor and file descriptors

Discussion in 'C++' started by Digital Puer, Jan 23, 2007.

  1. Digital Puer

    Digital Puer Guest

    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?
     
    Digital Puer, Jan 23, 2007
    #1
    1. Advertising

  2. Digital Puer

    Daniel T. Guest

    "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
    > 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.
     
    Daniel T., Jan 23, 2007
    #2
    1. Advertising

  3. Digital Puer

    Marcus Kwok Guest

    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
    > 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
     
    Marcus Kwok, Jan 23, 2007
    #3
  4. 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
    >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?


    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
     
    Roland Pibinger, Jan 23, 2007
    #4
  5. Digital Puer

    Daniel T. Guest

    (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?
     
    Daniel T., Jan 23, 2007
    #5
  6. On Tue, 23 Jan 2007 23:14:43 GMT, "Daniel T." wrote:
    >rpbg123@...com (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
     
    Roland Pibinger, Jan 24, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. JG
    Replies:
    5
    Views:
    429
    Lawrence Kirby
    Feb 8, 2005
  2. frs
    Replies:
    20
    Views:
    756
    Alf P. Steinbach
    Sep 21, 2005
  3. arun
    Replies:
    2
    Views:
    547
    benben
    Jun 13, 2006
  4. Jimmy Hartzell
    Replies:
    0
    Views:
    421
    Jimmy Hartzell
    May 19, 2008
  5. Jimmy Hartzell
    Replies:
    2
    Views:
    1,170
    Jimmy Hartzell
    May 20, 2008
Loading...

Share This Page