Re: [boost] pure virtual singleton

From: Jason Hise (chaos_at_[hidden])
Date: 2005-03-24 21:18:52

Jody Hagins wrote:

>On Thu, 24 Mar 2005 08:47:58 -0800
>Dan Rosen <dan.rosen_at_[hidden]> 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