[boost] Re: implicit smart pointer conversions

From: Dave Abrahams (abrahams_at_[hidden])
Date: 2000-03-19 09:55:18

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);
    }

    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.

[I find this argument more compelling for strings than for smart pointers,
though; I have used it with strings myself].