Boost logo

Boost Users :

From: Michael Nicolella (boost_at_[hidden])
Date: 2006-08-18 13:21:03


I think it's probably OK to break the cycle with a raw pointer (unless I am
missing something), as long as you're sure that nothing else can have a
shared_ptr to that B object (because then the B object isn't guaranteed to
be destroyed in that particular A's destructor, and then the ptr back to A
could be dangling). But if A is supposed to completely control B's lifetime
like that, why are we using a shared_ptr at all? Maybe auto_ptr or
scoped_ptr is a better choice?

-----Original Message-----
From: Scott Meyers [mailto:usenet_at_[hidden]]
Sent: Friday, August 18, 2006 10:05 AM
To: boost-users_at_[hidden]
Subject: [Boost-users] [SmartPointers] weak_ptrs, raw pointers, and cycles

I've recently realized that I just don't get something. Cycles of
shared_ptrs
are bad, because they can lead to resource leaks. To break a cycle, we're
encouraged to use weak_ptrs. Okay, but we could use raw pointers to break
the
cycle, too, and I can't see any advantage offered by the weak_ptr. If A
uses a
shared_ptr to B and B uses a weak_ptr to A, B's life will be shorter than
A's
(its destructor will be invoked from A's destructor and will run to
completion
before A's does), so there is no advantage to a weak_ptr being able to tell
if
it dangles. In this context, it never will. So it seems that using a raw
pointer to break cycles has no disadvantage over a weak_ptr, and it's more
efficient (i.e., smaller and faster). Clearly, I'm missing something. Can
somebody please explain what it is?

I understand that weak_ptrs have other uses (e.g., as observers), so my
question
is only about the advice to use weak_ptrs to break cycles.

Thanks,

Scott

_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net