Jump to content
  • Advertisement
Sign in to follow this  

Private destructor in VC++ 6.0

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

I have a Singleton class that has a private destructor, so that no idiot programmers can delete it. Is there some way to make it so that the Singleton instance can't even be deleted from within the Singleton class?

Share this post


Link to post
Share on other sites
Advertisement
If you don't provide any publicly accessible mechanism to delete it, the only way for someone to delete it would be to edit the code for the class itself and deliberately add code to delete it. If someone is able to do that (ie. they have access to your source code), nothing you can do will stop them!

Usually making the destructor private, commenting it with "prevent deletion of this object", and not providing a static Release() or similar function covers everything. If someone is still determined to find a way to delete it, well, I'd spend your time on something more useful if I were you...

...and this is of course assuming you stick with the decision to use a singleton, which I'm rarely convinced by personally.

Share this post


Link to post
Share on other sites
Yeah, there's been plenty of discussion here about the validity of the Singleton pattern. Basically, the consensus is that the Singleton Pattern is incorrectly used 99.99% of the time, and is only technically correct to use when dealing with a situation where an underlying hardware restriction necessitates it. Essentially, no application software should ever need to use a singleton, particularly games. In other words, only firmware and hardware interfaces (such as drivers) should use singletons, and even then are still best avoided where feasible.

Singletons are bad because they promote code-bleed, reduce encapsulation and promote quick-fixes over correcting the design.


As to your original question, yes, its possible but its a poor idea (though no poorer than using the singleton to begin with, I suppose; If you've drank the Singleton poison already, no one cares if you piss it out before you die.)


Read the singleton debate that's already been posted, and use the forum search to find others. Keep reading them until you're convinced that singletons are a bad idea. Don't code anything until you have.

And for Pete's sake, upgrade yourself to the free Visual C++ 2005 Express Edition (and install the Platform SDK following these instructions) before you drive yourself crazy. VC++ 6 is a broken compiler, and the IDE has come a long way since 6.0. You'll thank yourself later.

Share this post


Link to post
Share on other sites
I generally agree that the Singleton pattern is a bad idea. I'm writing a plugin to interface with an external program. The plugin can only ever interface with a single instance of the external program, and if a programmer EVER deletes the Singleton instance, the plugin will crash, taking a lot of stuff with it. I'm trying to write the Singleton to hide the idiocy of the software I'm interfacing with while still providing much of the power.

Lets put it this way, the Singleton is much better than the global functions/variables that it is replacing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Diltsman
Lets put it this way, the Singleton is much better than the global functions/variables that it is replacing.


Is it really? Could we see what exists to be replaced?

Often the best solution is to dump the functions and variables into a namespace, ensure that all the necessary work can be done via the functions (as opposed to handling the variables directly) and then simply not mentioning (via 'extern') the variables (or any helper functions) in the corresponding header file. That is, we gain the effect of 'private' in a class by simply omitting things from the header. This is how people used to do it in C (except they didn't have namespaces), after all [smile]

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!