Re: [boost] singleton raw pointer access

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-04-29 08:05:34

From: Jason Hise <chaos_at_[hidden]>
> Rob Stewart wrote:
> >From: Jason Hise <chaos_at_[hidden]>
> >
> >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_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;