|
Boost : |
From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-07-17 08:25:34
From: "Ed Brey" <brey_at_[hidden]>
> In the 1.28.0 distribution, intrusive_ptr includes a non-explicit
constructor and an assignment operator that take T*. This differs from
shared_ptr, which provides neither. This is at best inconsistent and at
worst dangerous. The danger is the same one that motivates shared_ptr to
not deal implicitly in raw pointers; e.g. a function taking an intrusive_ptr
can have an unmanaged pointer passed to where it can be unknowingly taken
over by the intrusive_ptr.
>
> Is there something unique about intrusive_ptr that makes it appropriate to
differ from shared_ptr?
<
Yes. intrusive_ptr<> can be safely constructed from a raw pointer that is
already being managed by another intrusive_ptr<>. This makes the implicit
conversion less dangerous. It's still possible to pass a pointer to a
stack-allocated object, of course; this is not intrusive_ptr's problem,
though. The object is expected to behave appropriately when it's use count
drops to zero. An 'auto' or 'static' intrusive-counted object should ignore
addref/release's.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk