[boost] Re: implicit smart pointer conversions

From: Borgerding, Mark A. (MarkAB_at_[hidden])
Date: 2000-03-20 09:23:58

> -----Original Message-----
> From: Dave Abrahams [mailto:abrahams_at_[hidden]]
> Sent: Sunday, March 19, 2000 7:53 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: implicit smart pointer conversions
> 
...
> 
> What's needed here are examples.  
...
 
> I would like to see examples which contradict this one, even 
> if they are
> contrived. This is not meant as a challenge, but as a way of 
> furthering the
> discussion.
> 

I sent an example on Saturday of the behavior I fear most from operator T*
http://www.egroups.com/group/boost/2673.html?

My concern involves automatic conversion of smart ptrs as return values.

I have had a couple more days to examine my beliefs and concerns, as well as
those of list members with differing viewpoints.  It looks like the danger
might be limited by a small change to the smart ptr interface and sufficient
programmer discipline.  

Small Change:
        shared_ptr operator T* changed from 
          operator T*() const throw()        { return ptr; }
        to 
          operator T*() throw()        { return ptr; }

Programmer Discipline:
        Make functions return 
                const shared_ptr<foo>
        instead of 
                shared_ptr<foo>

If both of the above are true, then the problem case would not compile.

Example:

const shared_ptr<int> GetNewInt() {return new int(0);}

int main()
{
        // legacy code likely to be broken
        int * pI = GetNewInt();// error -- shared_ptr<int>::operator int *
cannot be called on a const object

        // the way the code should be
        shared_ptr<int> spI = GetNewInt();// fine, constructs a shared_ptr
from a const&

        return 0;
}

I'm not thrilled about a solution that requires extra discipline on the part
of the user, but I guess I could live with it.
If this approach is used, the rationale needs to be documented.  

I agree with Beman about including rationale in the documentation.  I think
the reason it is not included more often is because the original rationale
is often discovered after hours or days of difficult debugging.  When the
code finally works, the developer gives a sigh of relief and moves on to
something else, feeling like he/she has already spent too much time on the
problem area to document much.  I admit I have been guilty of this in the
past -- and it usually comes back to bite me.

- Mark