Re: [boost] Re: Implicit construction in intrusive_ptr

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2002-07-17 12:57:18

----- Original Message -----
From: "Ed Brey" <brey_at_[hidden]>
Newsgroups: gmane.comp.lib.boost.devel
To: <boost_at_[hidden]>
Sent: Wednesday, July 17, 2002 12:31 PM
Subject: [boost] Re: Implicit construction in intrusive_ptr

> One point that might help clarify things is a statement on the intent of
intrusive_ptr.  I see it largely as a leaner alternative to shared_ptr,
useful when you always have a counted_base (or equivalent).  Is there any
more to it?
>
Yes it is.
Intrusive pointers are intended to be used when you want to detach the
lifetime management of the objects from the smart ptr.
The intrusive ptr manages only the count, not the object lifetime. This
gives you further control over the interaction of raw and smart usages of
the pointer.  If you don't need this external control, then maybe you
shouldn't use intrusive_ptr<>; I'm not sure this pointer is supposed to
replace shared_ptr<> just to get a smaller memory foot-print.

In the case you've shown, for example, there is nothing implicitly wrong
with 'fn' passing down &x to an intrusive pointer.
If the object received by 'fn' was originally allocated in the heap, the
program will run OK.
If it is auto/static, then sure someone must account for this and
intrusive_prt alone can't do much about it.
In such a case, anyway, the block were the automatic/static object is
constructed can add_ref it manually. This way, it can be safely taken by any
amount of intrusive_ptr<> within its frame since its count won't ever drop
to zero and it won't be ever 'deleted'.

Fernando Cacciola
Sierra s.r.l.
fcacciola_at_[hidden]
www.gosierra.com