how to delete references to objects from a container...
Hi forum members, I want to use boost's shared_ptr class for the connection pool class that i am writing. However, i have a requirement to delete the connection object (which is going to be the shared-ptr) explicitly based on certain checks like validity and expiry etc. If I store the shared_ptr, I want to know how to delete this explicitly from the stl container. According to my understanding shared_ptrs cannot be 'delete'd. So, how to achieve this...? Thanx in advance and regards, RV -- View this message in context: http://old.nabble.com/how-to-delete-references-to-objects-from-a-container..... Sent from the Boost - Users mailing list archive at Nabble.com.
If I store the shared_ptr, I want to know how to delete this explicitly from the stl container.
According to my understanding shared_ptrs cannot be 'delete'd. So, how to achieve this...?
You can delete shared_ptr from a container, just like you delete any element, using contaners member functions (like erase(), pop_front() etc). You cannot delete the *pointee* of the shared_ptr, because it might be shared. But if there's no other copy of the shared_ptr that you delete from your container, the pointee will be deleted as well.
rv_nath wrote:
Hi forum members,
I want to use boost's shared_ptr class for the connection pool class that i am writing. However, i have a requirement to delete the connection object (which is going to be the shared-ptr) explicitly based on certain checks like validity and expiry etc. If I store the shared_ptr, I want to know how to delete this explicitly from the stl container.
According to my understanding shared_ptrs cannot be 'delete'd. So, how to achieve this...?
shared_ptr's CAN be deleted(or reset to NULL), you can NOT directly delete the shared item that the shared_ptr is managing. When the last shared_ptr referencing the shared item is deleted(or reset) it will delete the shared item. There is also weak_ptr originally intended to break cycles which may be of use to you. Otherwise your design will need to communicate when to take appropriate actions. Jeff
Dear Jeff, Thanx for your quick reply. FUrther to the same question, can you please explain: > There is also weak_ptr originally intended to break cycles which may be of use to you. - the meaning of breaking cycles, and how it can help in this situation. It is said that a weak ptr doesn't increment the refcount. That means there is a possibility of the pointee object being deleted, while a weak ptr is holding a reference of it. So, in my understanding, if i return a weak-ptr to the clients of my object, then I will be able to delete my object at time of my choosing inspite of how many number of weak-ptr references the clients may have. But after this, the weak-ptr reference becomes invalid. Am I right? regards, RV Jeff Flinn wrote: > > rv_nath wrote: >> Hi forum members, >> >> I want to use boost's shared_ptr class for the connection pool class that >> i >> am writing. However, i have a requirement to delete the connection >> object >> (which is going to be the shared-ptr) explicitly based on certain checks >> like validity and expiry etc. If I store the shared_ptr, I want to know >> how >> to delete this explicitly from the stl container. >> >> According to my understanding shared_ptrs cannot be 'delete'd. So, how >> to >> achieve this...? > > shared_ptr's CAN be deleted(or reset to NULL), you can NOT directly > delete the shared item that the shared_ptr is managing. When the last > shared_ptr referencing the shared item is deleted(or reset) it will > delete the shared item. There is also weak_ptr originally intended to > break cycles which may be of use to you. Otherwise your design will need > to communicate when to take appropriate actions. > > Jeff > > _______________________________________________ > Boost-users mailing list > Boost-users@lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > -- View this message in context: http://old.nabble.com/how-to-delete-references-to-objects-from-a-container...-tp26710061p26712344.html Sent from the Boost - Users mailing list archive at Nabble.com.
rv_nath wrote: > Dear Jeff, > Thanx for your quick reply. FUrther to the same question, > can you please explain: > > There is also weak_ptr originally intended to break cycles which may be > of use to you. > - the meaning of breaking cycles, and how it can help in this situation. > > It is said that a weak ptr doesn't increment the refcount. That means there > is a possibility of the pointee object being deleted, while a weak ptr is > holding a reference of it. So, in my understanding, if i return a weak-ptr > to the clients of my object, then I will be able to delete my object at time > of my choosing inspite of how many number of weak-ptr references the clients > may have. But after this, the weak-ptr reference becomes invalid. Am I > right? (please don't top post) Yes, that's right. See: http://www.boost.org/doc/libs/1_41_0/libs/smart_ptr/weak_ptr.htm You'd have to lock the weak_ptr to access a shared_ptr to the resource, which would litter your code with a lot of conditionals to check to see if the shared_ptr is not null. While this may be a valid design approach in some cases, my first inclination would be to redesign taking into account the true nature of the relationships your dealing with, IMHO of course. Jeff
So, in my understanding, if i return a weak-ptr to the clients of my object, then I will be able to delete my object at time of my choosing inspite of how many number of weak-ptr references the clients may have. But after this, the weak-ptr reference becomes invalid. Am I right?
You never can *delete* an object (in the sense of invoking delete() operator), which is accessed through shared_ptr. It can be deleted by shared_ptr's deleter only. If you return to your clients weak_ptr's to a "living" object, they probably will lock() that weak_ptr in order to access the object, and the object will be deleted only after all the clients dispose their weak/shared ptrs.
On Dec 9, 2009, at 11:26 AM, Jeff Flinn wrote:
(please don't top post)
The real problem there was indiscriminate over-quoting. Please try to limit quoted text to the essentials for your reply. We have message archives for those who need to review the message history. -- David Abrahams BoostPro Computing http://boostpro.com
participants (3)
-
David Abrahams -
Igor R -
Jeff Flinn -
rv_nath