Jump to content
  • Advertisement
Sign in to follow this  
Bow_vernon

Global object's destructor not called when code crashes

This topic is 2754 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

However, if I put the object at main() scope, its destructor gets called even when crashing.

//this works
void main()
{
CBlah obj;
}
//this wont do
CBlah obj;
void main()
{
}

I need the destructor to be called(evn in a crash)but also to make the object accessible at the global scope..

Share this post


Link to post
Share on other sites
Advertisement
best solution: find a way to not need it to be at global scope. globals are always a last resort.

oh, and don't just pack it into a singleton :) no lipstick-on-a-pig solutions.

just have it in main, and pass it around as needed.

Share this post


Link to post
Share on other sites
But how? Im writing a logger class, which open file handle in constructor and close it in the destructor...it should be accessible at global scope. Oh and I'm avoiding those horrible singletons as you suggest, I dont like it either....

Share this post


Link to post
Share on other sites
Normally when a process is killed, the OS should close all open handles, so I wouldn't worry much about the case when the application crashes. Plus, when the application crashes, you don't really have all that much control about what happens.

You usually see a crash when for example a segmentation fault (or anything else that will trigger a hardware interrupt) is caught by a handler, but unless you dereference a null pointer, you really don't know what has happened before that. Your application might have been writing 50 megabytes past the end of an array in an endless loop before eventually hitting a page that isn't writable. Which means, any data in your logger class including the handle value could already have been overwritten with rubbish, and you don't know. There's simply no way you can protect yourself against what happens in a crash.

In case of C++ exceptions, everything will be smooth anyway, it's just the hard crashes that will bug you, and like I said, not much you can do there really. Even installing a vectored exception handler won't be 100% safe since you cannot know what happened before your handler is called.

Share this post


Link to post
Share on other sites
You could use a pointer in the global scope and set it to the address of an object that is created in the main...

Share this post


Link to post
Share on other sites
@japro: Thx man, I've already done that and it worked nicely. Im happy with that!
@samoth: Well I know that, It's just Im trying to write a memory manager also, not just a logger class.
OK now everything's smooth and nice, and Im sure there will be no more memory leak....

Share this post


Link to post
Share on other sites
my logger normally opened and closed for every single log. so all i did was log("bla") and be done with it. worked very well, and allowed to open the log while the app was running (opened in the browser and f5ed all the way to see the actual state).

so no need for the global.

otherwise, you could have it in the logger class / namespace to be at least not in the public domain per se.

Share this post


Link to post
Share on other sites
@dave: I ever did that too, the reason Im doing it this way is because I frequently write to log file (and should be fast), so open-close-ing file is no option (feel like shooting my own foot)

Share this post


Link to post
Share on other sites
@Dave: Well it's not a problem, anyway Im logging specific engine log at the logger constructor and destructor. By making sure the logger's destructor called, I dont have to log those specific info (it's automatically called)... and Im writing a memory manager too. what starts should finishes, rite?

Share this post


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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!