Re: [boost] Re: Re: bald singleton pointers

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-02-17 13:41:02

From: Jason Hise <chaos_at_[hidden]>
> Pavel Vozenilek wrote:
> 
> >template<.....>
> >T* unsafe_get_pointer(singleton<T>::pointer&) { ... }
> >
> >would be enough. Having one more class
> >for just one function feels as overkill.
> >
> >Local need for raw pointer should not mean
> >possibly global change in design.

Good idea Pavel.  That is simpler and is easy to grep for in
one's code base, just like "reinterpret_cast."

> I'm terribly torn on this issue.
> 
> Use of a raw singleton pointer is dangerous if it remains in use for a 
> long period of time, specifically long enough for the instance to have a 
> possibility of being destroyed.  If the singleton uses a real locking 
> policy the code using the raw pointer would have to lock the operations 
> manually.

The function's name is "unsafe_get_pointer."  Caveat emptor.  You
document the problems, such as undefined behavior due to
dereferencing the returned pointer after the Singleton has been
destroyed, and let the programmer deal with the consequences.

> On the other hand, a raw pointer is the only really feasible way to pass 
> a singleton pointer as a pointer to a non singleton base class.  Example:
[snipped]
> Thus, at this point my thought is that the C++ motto is 'trust the 
> programmer', so I'm thinking I should just provide the unsafe_raw_ptr (  
> ) member in the singleton, surround it with comments in all caps, and 
> document the heck out of it.

Putting the function in the class definition raises awareness of
it and lends it more credibility as a reasonable use of the
class.  Making it a non-member function keeps it rather separate
and gives it a bit of that "workaround" flavor.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;