SatView: Pointer Perfect, part 3.5 - BOOST::WEAK_PTR
(Page 4 of 4 )
The boost::weak_ptr stores a ‘weak’ reference to an object that is already being managed by a boost::shared_ptr. It has no effect on the reference count of the shared pointer. Boost provides you with a weak_ptr, because it is very easy to create a circular reference with shared_ptrs. Check out the following relationship (which by the way can only be created with shared_ptrs since these allow for incomplete types):
#include <boost/shared_ptr.hpp>
class Parent; // forward declaration
class Child; // forward declaration
class Parent {
public:
boost::shared_ptr<Child> m_pChild;
};
class Child {
public:
boost::shared_ptr<Parent> m_pParent;
};
int main(int argc, char *argv[]) {
boost::shared_ptr<Parent> parent(new Parent);
boost::shared_ptr<Child> child(new Child);
parent->m_pChild = child;
child->m_pParent = parent;
child.reset(); // letting go of pointer
(void)printf(“child’s ptr is 0x%p.\n”, child.get());
(void)printf(“child’s refcount is %d.\n”,
parent->m_pChild.use_count());
return 0;
}
When you compile and run this example, your output will be:
child’s ptr is 0x00000000.
child’s refcount is 1.
We introduced a circular reference by letting the parent point to the child, which in turn points back to the parent. When the child is created its reference counter is set to 1 and as soon as it is copied into the parent, its reference counter is increased to 2. Same story goes for the parent.
Now if we are to reset/destroy the child smart pointer, parent will still hold a reference to it. If we are to reset/destruct the parent smart pointer, that one will still have a reference count of 1 as well: neither will have destroyed the object they contain. But child cannot be used anymore, since it contains a NULL pointer! The same is possible with parent and we will have lost access to both objects, which have not been destructed because their reference count is still 1!
To prevent cycles like these, you can use the boost::weak_ptr. Child could break the circle like this:
class Child {
public:
boost::weak_ptr<Parent> m_pParent;
};
shared_ptrs manage an object by observing how many pointers are making use of it, hence keeping it alive (which becomes a problem with circular references). A weak_ptr only references that object but is neglected in the efforts used to keep it alive. Thus when the last shared_ptr is destructed and the object is deleted, the weak_ptr becomes invalid. If you need access to the object contained in a weak_ptr, you can convert it to a shared_ptr using a constructor designed for this purpose (unless the object has been deleted by the last shared_ptr referencing it of course).
#include <boost/shared_ptr.hpp>
#include <boost/weak_ptr.hpp>
int main(int argc, char *argv[]) {
boost::shared_ptr<int> pOne(new int(1));
boost::shared_ptr<int> pOther = pOne;
boost::weak_ptr<int> pWeak(pOne);
(void)printf(“ref count = %d.\n”, pOne.use_count());
pOther.reset();
(void)printf(“ref count = %d.\n”, pOne.use_count());
boost::shared_ptr<int> pFromWeak(pWeak);
(void)printf(“ref count = %d.\n”, pFromWeak.use_count());
pOne.reset();
(void)printf(“ref count = %d.\n”, pFromWeak.use_count());
pFromWeak.reset();
try { boost::shared_ptr<int> pRestore(pWeak); }
catch (…) { (void)printf(“exception thrown!\n”); }
return 0;
}
The code above provides the following output:
ref count = 2.
ref count = 1.
ref count = 2.
ref count = 1.
exception thrown!
So weak_ptr is useful to break circular references, though you have to make sure you never try to restore something that is not there anymore.
Next article will be the last on pointers and discuss/demonstrate some of the common pitfalls you will encounter when using them. I hope you have enjoyed the trip so far. If smart pointers have captured your interest, be sure to check out www.boost.org and read up on the boost::intrusive_ptr when size matters to you (sometimes size matters, sometimes how you use it right?).
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |