Re: shared_ptr cycles
On May 7, 1:37 pm, Christopher <cp...@austin.rr.com> wrote:
On May 6, 11:31 pm, "Chris M. Thomasson" <n...@spam.invalid> wrote:
"Christopher" <cp...@austin.rr.com> wrote in message
news:38d6d0d2-ec52-4baf-952a-a6aff3b52f4f@t10g2000vbg.googlegroups.com..=
..
I am not sure I understand this. I am need to before I get
myself in trouble!
"Because the implementation uses reference counting,
cycles of shared_ptr instances will not be reclaimed. For
example, if main() holds a shared_ptr to A, which directly
or indirectly holds a shared_ptr back to A, A's use count
will be 2. Destruction of the original shared_ptr will
leave A dangling with a use count of 1. Use weak_ptr to
"break cycles." "
How would a shared pointer to A, directly or indirectly
hold a shared pointer back to A? Shared pointers hold
regular pointers as far as I know?
This is the only situation I can come up with, which I
would more easily describe as "If any shared pointer that
already contains a raw pointer B, is assigned to a shared
pointer that already contains B, the reference count is
incremented and will not be decremented back to zero, when
those shared pointers are destroyed" I am not even sure if
that would happen, because ...isn't the reference count
decremented when a shared pointer is assigned?
int main()
{
boost::shared_ptr<MyClass> ptr1 = new MyClass();
boost::shared_ptr<MyClass> ptr2 = ptr1; // increment ref coun=
t
to 2
ptr1 = ptr2; // decrement ref count for assignment and then
increment?
// what's the ref count? Is this what they are describing as a
"cycle"?
return 0;
}
[...]
That's not an example of a cycle; try something like this:
<quick and dirty pseudo-code>
______________________________________________________________
struct foo {
boost::shared_ptr<foo> m_cycle;
};
int main() {
{
boost::shared_ptr<foo> p(new foo);
p->m_cycle = p;
}
// the `foo' object created above is now leaked!
return 0;}
______________________________________________________________
I don't understand the underlying reason the reference count
becomes incorrect.
It doesn't become incorrect. The rule for reference counting is
that the object will be deleted when there are no more pointers
to it. In the above, there will be no more pointers to the foo
object in p only once the foo object has been deleted. And it
won't be deleted until there are no more pointers to it.
This is what is called a cycle: starting at one of the managed
objects, you can navigate, using shared_ptr, through a cycle
leading back to the original object. So even if all pointers
external to the objects cease to exist, there are still pointers
to them.
The obvious solution to this problem is to use garbage
collection for memory management, which frees the memory if no
"reachable" pointers to it exist---that "reachable" makes a
critical difference. Often, a better solution would be to not
use dynamic allocation at all. And in many cases where dynamic
allocation is necessary, the objects involved have definite
lifetimes anyway, so no lifetime management is necessary (nor
should be used, since it will violate the contract). In
practice, there are really very few cases where shared_ptr is
appropriate.
I need to understand it more thoroughly to prevent it. Can we
walk through what the reference count is at each step?
Here is what I envision, but might be incorrect:
{
boost::shared_ptr<foo> p(new foo); // ref count is 1
p->m_cycle = p; // ref count becomes 2 because it
was assigned} // it was actually assigne=
d to
m_cycle
--- block end-----
// p is being destroyed because it is out of scope
// ref count becomes 1
// When p is destroyed, m_cycle still contains a raw pointer that
points to the address of foo
// m_cycle is no longer accessable
So, this scenario is when a smart pointer<t> that points to an
t object that contains a smart pointer<t> If I make sure that
no object contains smart pointers capable of pointing to the
object type, am I safe? Are there more scenarios I should be
wary of?
Cycles may involve more than one object, and may involve objects
of different types. If you never have a shared_ptr to an object
which might contain a shared_ptr, you are safe. Otherwise, the
analysis is more difficult. In practice, this isn't too great
a problem. Objects to which shared_ptr is reasonable generally
don't have shared_ptr, naturally. Provided you use shared_ptr
intelligently.
(In my own RefCntPtr, the objects pointed to must derive from
RefCntObj. This is a lot more robust than shared_ptr, since you
can't get two different counters for the same object, and by
requiring the specific base class, it is easy to ensure that
RefCntPtr can only point to objects which are designed with it
in mind---and which, thus, don't contain RefCntPtr.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34