Constructing a non-constructable class

[LB]

This is relatively simple:

class PrivateClass
{
  PrivateClass(){}
  static PrivateClass Cheat;
};

PrivateClass PrivateClass::Cheat;

The reason I want to do this is so that I can make use of the destructor being called at program end, even if the program ended via an unhandled exception. Now, what I want to know is:
1. Should I even bother making it unconstructable like this? The reason I did was because I saw it as a very bad idea to instantiate more than one of these.
2. Is there a better, platform-independent alternative?
3. Am I doing something wrong or missing something here?

[kbw]

Check out Singleton and atexit
http://www.infernodevelopment.com/singleton-c
http://www.cplusplus.com/reference/clibrary/cstdlib/atexit/

[LB]

On atexit,
"The function pointed by the function pointer argument is called when the program terminates normally."

What if the program does not terminate normally?

[kbw]

What if the program does not terminate normally?

That's a non-deterministic event. You can't deal with that within the program that's been terminated.

EDIT: termination thru an unhandled exception is not a non-deterministic event. atexit functions are called.

[3hM2Nwbp]

I'm pretty sure this has already crossed your mind, but were looking for a more elegant solution.

int main()
{
    int returnValue = 0;
    try
    {
        // Program Body
    }
    catch(...)
    {
        //Unhandled Exception is ultimately caught
        returnValue = -1;
    }
    // Always terminate normally
    return returnValue;
}

[kev82]

Correct me if I'm wrong, but the whole point of exceptions and destructors is that in an unhandled exception, the destructors WILL be called. Isn't this the whole principle on which RAII is based?

So just do:

int main() {
struct s {
~s() { //whatever
}
} an_s;
...
...
}

As long as your process doesn't do anything daft like abort. then you'll be fine. I'm also not certain about the different compiler guarantees about destruction of static objects. My intuition says it's a bit of a minefield.

The previous solution is ok, but I think it encourages ignoring exceptions, which I don't like. I was working on reverse engineering a project last year that had a lot of

try {
//stuff
} catch (...) {
}

It wasn't fun, and for some of it, once I knew what that section of was supposed to do, I just scraped it, and rewrote it myself.

[LB]

Thanks for the replies. Unfortunately it's kinda difficult to put a try-catch block in the global scope, especially with a library I can't modify. I think I'm going to do this differently now reading your helpful replies :)

[ne555]

http://stackoverflow.com/questions/222175/why-destructor-is-not-called-on-exception

If no matching handler is found in a program, the function terminate() (_except.terminate_) is called. Whether or not the stack is unwound before calling terminate() is implementation-defined.

@L B:

The reason I want to do this is so that I can make use of the destructor being called at program end

¿what is the destructor supposed to do?
I was trying something similar for Keep the console open http://www.cplusplus.com/forum/beginner/33789/
Maybe a wrapper could help you

[LB]

Keeping the console open is where I got the idea for this, it looked so amazingly simple that I thought it had to have other uses...I guess I got carried away and started to do things in ways I shouldn't be doing them in. ;)