• Advertisement
Sign in to follow this  

What methods should my destructor contain?

This topic is 1968 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello,

This is just a quick question but it has been bugging me a while. I have a GameEngine class (probably should be renamed to something less Grande). I have it set so that, before it does all the standard stuff like deleting pointers, destroying bitmaps, it saves the current game. Snippet below:
[source lang="cpp"]GameEngine::~GameEngine(void)
{
_SaveData("GameData.txt", a_PlayerOne->f_GetScore(), a_PlayerTwo->f_GetScore());
// For every new/BITMAP*, there must be a matching delete/destroy.
delete a_Grid;
delete a_PlayerOne;
delete a_PlayerTwo;
destroy_bitmap(a_PlayerO);
destroy_bitmap(a_PlayerX);
// TODO: (Shape that appears underneath cursor
/*if(shapeCursor != NULL){
destroy_bitmap(shapeCursor);
}*/
destroy_bitmap(temp); // TODO:
destroy_bitmap(a_Buffer);
}[/source]
Is this the correct thing I should be doing, or should I make an explicit call to it in the code, before the destructor is run? Are there any dangers of leaving it until the class destructs?

Regards,

Stitchs.

Share this post


Link to post
Share on other sites
Advertisement
My main problem with that code is that another programmer reading the code that uses this class will not expect that the destructor will save the game to a file, because it's unusual for a destructor to do such things.

Another problem is the hard-coded filename. If you wanted to make it more flexible so you could save the game somewhere else, you would need to pass the filename as an argument, but the destructor doesn't take arguments. This is another indication that saving should be done in a method, not the destructor.

Share this post


Link to post
Share on other sites
Because of stack unwind semantics, C++ destructors should not contain any function calls that can fail when passed valid arguments. Freeing resources is fine. Any function that needs to allocate resources in order to function, like acquire a file handle, is not.

On another note, identifiers beginning with an underscore followed by a capital letter are reserved for the implementation. Using such identifiers in your own code can cause problems on different platforms.

Share this post


Link to post
Share on other sites
Thanks for the swift responses. I had a feeling that how I had done it was incorrect, I just wanted to double check and couldn't word my question correctly in a net search.

I'll move into implementing some sort of close-down function that is called independently of the destructor.

Regards,

Stitchs

Share this post


Link to post
Share on other sites
What you did wasn't incorrect, its just bad practice effectively. As its already been pointed out, if I was to use your class, I would not expect when it went out of scope/or I deleted it, that it would save a game file. My port of call is to create classes as if they are intended to be used by someone else, unless of course, those classes will never be used by someone else. If that makes any lick of sense .... hmm. Edited by theark

Share this post


Link to post
Share on other sites

[quote name='theark' timestamp='1346623333' post='4975846']
As its already been pointed out, if I was to use your class, I would [color=#ff0000]not expect when it went out of scope/or I deleted it, that it would save a game file.

[size=2](Corrected, to avoid potential confusion from the missing word)
[/quote]

Thanks, must have missed that when reading it back. :)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement