Boost logo

Boost :

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:
> 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           
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at, gregod at, cpdaniel at, john at