By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,227 Members | 1,310 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,227 IT Pros & Developers. It's quick & easy.

Should resource wrappers auto cleanup on destruct?

P: n/a
(I searched the FAQ, but didn't find anything relevant -- if there is, please
post a link.)

Is there a design paradigm that indicates that a class that manages an external
resource should automatically perform clean up in the destructor?

For example, suppose the following file-wrapper class.

// begin

class file
{
private:
int fileHandle;

public:
file()
{
fileHandle = 0;
}
void open(char * fileName)
{
fileHandle = MySystemIO::OpenFile(fileName);
}
void close()
{
if (fileHandle)
{
MySystemIO::CloseFile(fileHandle);
fileHandle = 0;
}
}
~file()
{
// call close() here or not?
// close();
}
}

// end

I realize that from a /documentation/ standpoint, I can do either and just
document wether or not the destructor performs cleanup

-- however --

I'm mostly interested in a self-documenting code perspective, where (external)
documentation isn't referenced.

Comments???
Jul 23 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Julie wrote:
(I searched the FAQ, but didn't find anything relevant -- if there is,
please post a link.)
[redacted]


Google for "RAII" (Resource Acquisition Is Initialization).

Jul 23 '05 #2

P: n/a

"Julie" <ju***@nospam.com> wrote in message
news:40fKd.2926$5t.303@fed1read07...
(I searched the FAQ, but didn't find anything relevant -- if there is, please post a link.)

Is there a design paradigm that indicates that a class that manages an external resource should automatically perform clean up in the destructor?
Yes. Stroustrup's "RAII" ("Resource Acquisition Is Initialization").
For example, suppose the following file-wrapper class.

// begin

class file
{
private:
int fileHandle;

public:
file()
{
fileHandle = 0;
}
void open(char * fileName)
{
fileHandle = MySystemIO::OpenFile(fileName);
}
void close()
{
if (fileHandle)
{
MySystemIO::CloseFile(fileHandle);
fileHandle = 0;
}
}
~file()
{
// call close() here or not?
// close();
}
}

// end

I realize that from a /documentation/ standpoint, I can do either and just
document wether or not the destructor performs cleanup

-- however --

I'm mostly interested in a self-documenting code perspective, where (external) documentation isn't referenced.

Comments???


IMO the purpose of a dtor is exactly that: put things back the
way you found them.

-Mike
Jul 23 '05 #3

P: n/a
red floyd wrote:
Julie wrote:
(I searched the FAQ, but didn't find anything relevant -- if there is,
please post a link.)
[redacted]

Google for "RAII" (Resource Acquisition Is Initialization).


Thanks.
Jul 23 '05 #4

P: n/a
Mike Wahler wrote:
IMO the purpose of a dtor is exactly that: put things back the
way you found them.
This is a rather Sisyphisian view of class design, isn't it? Won't clients start
complaining that no work is getting done? :-)
-Mike


Jonathan
Jul 23 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.