From: Jason Hise <chaos@ezequal.com>
Rob Stewart wrote:
From: Jason Hise <chaos@ezequal.com>
Note that I can write this:
class A { ... }; // whatever the proxy's name is: typedef boost::singleton<A>::some_proxy proxy_type; proxy_type proxy(s.operator ->()); proxy->whatever();
Actually, the proxy type (which is called access_pointer in the code) is a private member class of the pointer class, and thus variables of that type cannot be created or talked about by client code.
Good.
[a proxy type for operator *()] means I can write
A & object(*proxy);
or
A & object(proxy.get_object());
and then I can do what I like with object.
Ahh, I think I understand now. So essentially, pointer::operator * () would return a 'smart reference' class instance?
Yep.
Similarly, operator *() can return the same (or a similar) proxy thus keeping the object alive during its use. If that proxy provides a conversion operator (gasp!) to the object managed by the singleton smart pointer, then you get complete safety and access to the raw object.
The conversion operator (probably only appropriate on a second proxy type) make this possible:
s/make/makes/
A & object(proxy);
This is clever and would probably work. However, I have two questions:
A) What benefits would a 'smart reference' provide that the smart pointer doesn't already?
Safe access to the controlled object that you don't get with get_unsafe_ptr().
B) Would such benefits outweigh the fact that client code would now be capable of accidentally storing and using a real reference to the singleton? For instance:
If you provide get_unsafe_ptr(), the client can already do all of those things. What I'm suggesting adds safety. You can choose to provide what I'm describing via a member function other than operator *() just so it isn't so easy, if you like. Either way, you need to document the things one shouldn't do with that level of access to the object.
In almost every circumstance, it is preferable for client code to use and pass around singleton::pointers rather than singleton *s, just like it is preferable for client code to use smart pointers to manage memory rather than trying to manage memory and raw pointers manually. Managing them manually can be done safely, but it is harder and error prone.
I understand the motivation for the original question. I'm just having a hard time getting you to see my point, it would seem. Hopefully, spelling out more of the details has helped.
I think I understand your idea now, please correct me if I am mistaken.
By George, I think he's got it! -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;