Re: shared_ptr cycles
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 =
count
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;}
______________________________________________________________- Hide quot=
ed text -
- Show quoted text -
I don't understand the underlying reason the reference count becomes
incorrect. 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 assigned 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?
I am trying to come up with some method of thinking that I can prevent
a cycle from occuring as I implement my objects.
So far, I beleive my current scenario to be a safe one:
where I have an object that contains a smart pointer to differant
object type.
I implement a copy constructor for the object
I assign the smart pointer member to the copied object's smart pointer
member.
I do the same in an assignment operator
Should I be checking that the two smart pointers lhs and rhs do not
already point to the same thing before assignment?
Or am I safe?
I want to have this down pat as other scenarios are sure to arise.