views:

100

answers:

1

I'm using Boost/shared_ptr pointers throughout my application. When the last reference to an object is released, shared_ptr will delete the object for me. The objects in the application subscribes to events in a central location of the application, similar to the observer/subscriber pattern.

In the object destructors, the object will unsubscribe itself from the list of subscriptions. The list of subscriptions is essentially just a list<weak_ptr<MyObject> >. What I want to do is something similar to this:

Type::~Type()
{
  Subscriptions::Instance()->Remove(shared_from_this());
}

My problem here is that shared_from_this cannot be called in destructors so the above code will throw an exception.

In my old implementation, the subscription list was just a list of pointers and then it worked. But I want to use weak_ptr references instead to reduce the risk of me screwing up memory by manual memory management.

Since I rely on shared_ptr to do object deletion, there's no single place in my code where I can logically place a call to Unsubscribe.

Any ideas on what to do in this situation?

+1  A: 
  1. You can destroy the objects via Subscription instance, then it'll automatically remove the pointers.
  2. You can forget about removing them from subscriptions -- the weak_ptr's wont be able to be locked anyway, then you can remove them.
  3. You can assign an unique ID to every object and then remove via the unique ID not the shared_ptr
  4. You can pass a normal pointer to Remove instead of a shared one -- it will serve as an "ID".
Kornel Kisielewicz
1) The objects are shared among several users who have connected to the server using TCP/IP. Making the Subscription instance the owner of these objects would be a bad design choice in my software.2) The problem is if no-one tries to notify these objects. Then the objects would live forever; resulting in an memory leak.3) Yes, this is what I probably will do. When subscribing, the client receives a subscription key which he'll use when unsubscribing.4) This was what I did before. I want to reduce the number of rawa pointers in the app though.
Martin
Kornel Kisielewicz
@Kornel2. If he stores them in a linked list/std::list, it won't be costly to remove them. The real cost is in the lock implementation every time he passes messages to the list of subscribers. He already has this cost, though.
Merlyn Morgan-Graham
@MartinMaking the object subscribe/unsubscribe itself is one of many potential choices, and it couples the object strongly to the subscription mechanism and/or exact object it is subscribing to. That choice stuck you w/ the requirement that you allow lazy unsubscription. If you push the logic that hooks up the publisher/subscriber elsewhere, you might get more control over when it is called, and be able to ensure that it is called without relying on lazy evaluation for every event pushed to subscribers, or reference counting behavior.Sorry for all the recomments. No edit feature :)
Merlyn Morgan-Graham