Boost logo

Boost :

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.


> >[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?


> >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:


> >
> > 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

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

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