Jody Hagins wrote:
On Thu, 24 Mar 2005 08:47:58 -0800 Dan Rosen <dan.rosen@gmail.com> wrote:
Hi Jason,
I haven't looked at singleton in any detail, so I can't answer your real question...
I do not understand what Jason is after either...
Alright, allow me to clarify. I want the singleton to behave as follows: class test : public singleton < test > { // no constructors or destructor provided // all of the defaults are generated }; int main ( ) { client c; // should still be illegal, and fail to compile return 0; } I do not want to force client code to define protected constructors and destructors if they would not normally need them. But the only way to disable creation without explicitly making the functions in the client class protected is to somehow make the client class pure virtual. This is achieved with a pure virtual function in the base with an obfuscated name client code is unlikely to implement on its own, and when the client fails to implement this function, the client class becomes pure virtual, and thus, is not creatable. Adding this virtual function adds overhead to the class. So I want to only provide this check in debug mode. My thinking is that all illegal uses will be caught, and then the release mode version won't have to pay the price for the safety net. My main worry is that the hole I am leaving in release mode could potentially be abused. Is disabling the check in release mode a good idea, or potentially dangerous enough that I should always leave the check enabled? Would it perhaps be better to check for a different symbol than NDEBUG, so that by default the check would always be enabled, but client code could explicitly disable the check if the overhead was a problem? Is there another way altogether that I can do this check without the overhead? As always, I am open to suggestions. -Jason