Abstract class for several screens, trouble with destructors

[oddek]

Hi.

Been using SFML for a building a tetris clone for learning purposes. In order to get a start menu, i wanted to add several screens and found this example: https://github.com/SFML/SFML/wiki/Tutorial:-Manage-different-Screens.

This worked perfectly, but i wanted to make the background and headline the same for all screens, so i have the code for this in the constructor of the abstract base class. Still works perfectly.

The trouble started when adding a destructor for the base class, i have tried several ways:

//in .h:
virtual ~cScreen() = 0;
//in .cpp:
cScreen::~cScreen() { }
 

or

//in .h:
virtual ~cScreen();
//in .cpp:
cScreen::~cScreen() {};
 

Or just:

//in .h:
~cScreen();
//in .cpp:
cScreen::~cScreen() {}
 

I suddenly got strange errors in the destructor for Screen_1 which looks like this:

//.h:
~Screen_1();
//in .cpp:
Screen_1::~Screen_1()
{
        for (auto i : texts) delete i;
        for (auto i : shapes) delete i;
}
 

The error comes from trying to delete the contents of texts, in debugging i see that all the members of Screen_1 is given strange values, like the size of texts is 0, and int members which are set to say 5, suddenly has max_int value. Some of the time visual studio says that the heap has been corrupted.

I've tried different ways of creating the objects in main as well

cScreen* s = new Screen_1();

or

Screen_1* s = new Screen_1();

etc.


Without having a destructor in the base class everything works fine, and of course i don't really need it, but i want to understand what is really happening here, and why.

It almost seems as if when the destructor for the derived class is called it is already corrupted or deleted, but when the abstract destructor is pure virtual it is never supposed to be called, is it?

I've tried both with and without actual stuff happening in the abstract destructor body.

Any help would be greatly appreciated.

[Laurent]

That's a C++ question that has nothing to do with SFML. Please use dedicated forums (stackoverflow, ...) next time, here we try to focus on questions about SFML itself

To answer your question: the destructor should be virtual (and defaulted if empty), and you most likely have your object already destroyed when you see those strange values in the debugger. I wouldn't say that it "works" without the destructor, it's just that the problem is less visible.

If you want to get more help, you should post a complete and minimal code that reproduces the problem. Using smart pointers (std::unique_ptr, most likely) would help avoiding errors, too.

[oddek]

Hi.

Thanks for the fast reply.

Yeah, you're right. I don't know why, but for some reason i thought it had to do with SMFL.

You were also right in your second paragraph, it did not work without the destructor either actually. And your third paragraph is great advice for posting a problem or just debugging on your own, because when i was cutting all excess code to get to the core of the problem i found the reason:

Screen_1::~Screen_1()
{
        for (auto i : texts) delete i;
        for (auto i : shapes) delete i;
}

This would be okay i guess if the objects they where pointing to were on the heap, but, these vectors actually just point to class members on the stack, they go out of scope when deleting the object either way, so it's just foolish to try to delete them in the destructor of course.


Thanks a lot for your help!


PS:
About using smart pointers, i'm about to get into them, i read everywhere that in modern c++, youre "never" supposed to use the word new or delete. But the thing is that i'm just out of my first class of c++ in uni, and there we where taught to do it this way. = p

[Laurent]

I'm glad my reply was helpful, and that you could solve your problem