[boost] Re: implicit smart pointer conversions

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-03-19 13:20:51

From: Dave Abrahams <abrahams_at_[hidden]>
> on 3/19/00 5:01 AM, Kevin Atkinson at kevinatk_at_[hidden] wrote:
> 
> >>> I think the slight unwieldiness of using get() is a small
> >>> price to pay for fewer runtime errors.  If I have to choose between
> >>> compile-time checks and ease of use,  I will choose the compile-time
> >>> checks nearly every time.
> >> 
> >> Indeed, some of us argued for naming them member of auto_ptr<> that
> >> reveals the raw pointer value "auto_ptr<>::leak()".
> > 
> > With an auto pointer you almost have to use get because if you use another
> > auto pointer you transfer ownership.  If you need to say pass the pointer
> > to a function you need to use get(), what the hell is wrong with that.
> 
> 
> This displays the analogous problem for shared_ptr:
> 
>     void too_many_owners(T* p)
>     {
>         shared_ptr<T> x(p);
>     }

I think this is why Boris keeps suggesting that rather than
initialize shared_ptr with a constructor from T* we should have
a special operator new.  The above is clearly a dangerous thing
to do.

>     void oops(shared_ptr<T> p)
>     {
>         too_many_owners(p);
>     }
> 
> On the other hand, the practice of tightening up legacy interfaces by
> dropping in a more-robust type in place of a less-robust one is an extremely
> powerful one. Sometimes, an implicit conversion can help you add some
> robustness quickly, without drilling all the way down to each leaf function
> and changing its parameter types. Yes, if we had time to rewrite all code
> from scratch, we would have no legacy interfaces. If you follow the
> principle that rewriting code which already works is a BAD THING, then you
> just want to use your more-robust type in new code.

And if you don't have source rewriting may be impossible.
 
> [I find this argument more compelling for strings than for smart pointers,
> though; I have used it with strings myself].

I never liked the standard library string design, but that is
another story.