Boost logo

Boost :

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-04-29 11:59:23


From: Jason Hise <chaos_at_[hidden]>
> Rob Stewart wrote:
>
> >>> 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().
> >
> But that's what the smart pointer itself already provides. In what
> circumstances would it be better for client code to work with a smart
> reference than with a smart pointer? The smart pointer provides access

The very one you started this thread with! You asked whether
get_unsafe_ptr() should be spelled operator *().

You wanted to provide access to the raw pointer/reference in
order to allow for polymorphic usage. The proxy to which I've
been referring provides a safe means for that because the client
can grab and hold a smart reference which can converts
(explicitly or implicitly, your choice) to T & and T *.

> to singleton members via the -> operator. A smart reference would be
> unable to provide access to singleton members via the dot operator
> without first being cast, assigned, or copied into a reference.
>
> Why would client code prefer this:
> void Foo ( )
> {
> MySingleton::reference r = *( MySingleton::pointer ( ) );
> static_cast < MySingleton & > ( r ).DoSomething ( );
> }
>
> to this?
>
> void Foo ( )
> {
> MySingleton::pointer p;
> p->DoSomething ( );
> }

That wasn't the purpose and of course you wouldn't choose the
former.

> It seems to me that smart references would be too clumsy to work with,
> and this would encourage client code to store and use real references
> just to avoid all the casting.

Are we back on track?

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk