[boost] Re: bald singleton pointers

From: Dave Handley (dave_at_[hidden])
Date: 2005-02-13 13:28:55

Jason Hise wrote:

>
> I would like to get general feedback on a feature that has been
> requested.  Some background:
>
> Right now, my singleton pointer classes serve a variety of purposes.  In
> the first place, they are the access mechanism for a singleton.  Any
> pointer constructed immediately points to the singleton instance (or
> possibly null if the instance hasn't been created yet).  If the
> singleton uses instant_creation, the first pointer created creates the
> singleton instance.  When a member is accessed through a singleton
> pointer, an intermediate pointer type performs locking, and if
> lazy_creation is set it may also create the singleton instance.
> Regardless of the lifetime mechanism used, when the singleton instance
> gets destroyed all pointers instantly reflect this by becoming null.
>
> It has been suggested that I provide a mechanism to get a bald pointer
> to the instance, such as an unsafe_ptr member function of either the
> pointer class or the singleton itself.  I feel that such a mechanism
> would be very dangerous, because the bald pointer could not perform lazy
> creation, it would not lock the operations, and it would not reflect
> when the singleton is destroyed.
>
> Are there instances in which allowing bald pointers to exist is
> necessary and/or useful?
>

The only instance that I can think of where you may want to do this is in a 
multi-threaded environment.  And even then only in a very specific set of 
circumstances.  Specifically, you may want to do this when you don't want 
the overhead of a lock, but, for some other reason, you can absolutely 
guarantee that concurrent access to the object (or parts of the object you 
are accessing) is valid.  If I'm honest though, I'm having some difficulty 
convincing myself that something like this would actually genuinely be 
useful.  Perhaps if you could get a "bald pointer" through a protected 
member, that was therefore only accessible to derived classes (hence the 
singletons themselves).  This could be useful to build into a static access 
function that provided a safe pointer, but perhaps without the overhead of a 
lock?

Personally, I would be quite reluctant to provide such a feature...

Dave Handley