Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk