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
> void oops(shared_ptr<T> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk