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