2

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?

curiousguy
  • 8,038
  • 2
  • 40
  • 58
Martin
  • 471
  • 3
  • 6
  • 1
    You have hit one one of the problems with relying on shared pointers - they are no substitute for design. –  Dec 18 '09 at 20:14
  • It was intended to be helpful. The number of answers here that say "use a shared pointer", when the answerer has no real idea of the problem. is frightening. IMHO, using a shared pointer should always be questioned. If you had done that, you might have noted the Unsubscribe problem earlier. –  Dec 18 '09 at 20:40
  • What might be more helpful, Neil, is pointing out where the design flaw might be, and giving an idea of how that could be fixed. I've tried to do that in my comments below. You are correct, though. Defaulting to garbage collection/relying on destructor semantics may be a red flag for design flaws. – Merlyn Morgan-Graham Dec 18 '09 at 21:21
  • Neil posted a comment. Of course it'd have been more helpful to go into further detail, but then he might as well have posted it as an answer. – jalf Dec 18 '09 at 23:43

2 Answers2

1
  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
  • 55,802
  • 15
  • 111
  • 149
  • 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 Dec 18 '09 at 20:42
  • 1. What I meant was that you call Subscription->Release(shared_ptr&). and then it removes the weak_ptr and resets the passed pointer. 2. You can do a sporadical wipe, but that might be costful -- and it would only be the weak_ptr's that'd live, the objects themselves would be dead. 3. An unique ID has many other benefits :) 4. Good point. – Kornel Kisielewicz Dec 18 '09 at 20:47
  • @Kornel 2. 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 Dec 18 '09 at 21:12
  • @Martin Making 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 Dec 18 '09 at 21:17
  • @MerlynMorgan-Graham "_If he stores them in a linked list/std::list, it won't be costly to remove them._" You mean even if the list is quite long? I disagree. – curiousguy Dec 13 '18 at 01:57
  • @curiousguy cool. Glad to know your opinion, random stranger person 9 years later. Elaborate if you want to contribute something useful to this conversation, lol – Merlyn Morgan-Graham Jan 02 '19 at 17:01
  • Woah, it's been 9 years since this question? Time flies D:. @curiousguy last time I've checked, removal from a linked list was O(1). – Kornel Kisielewicz Jan 03 '19 at 19:33
  • @KornelKisielewicz How do you determine which node to remove? – curiousguy Jan 03 '19 at 20:12
0

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

It will throw an exception because it's expired, by definition, in a destructor.

So what do you want anyway? An "expired" shared pointer? Just create an empty shared pointer.

Or an expired weak pointer?

Maybe if you notice that the "problem" isn't shared_from_this throwing (it's a symptom) but all owners being inherently already reset or destroyed at that point and the weak pointers being expired and equivalent to an empty default created weak pointer (*), so you just should pass a default initialized weak pointer.

Also Subscriptions::Instance()->Remove(weak_OR_owning_pointer) makes no sense either way (with either weak or owning pointer) as you can't compare a weak pointer to anything, you can only try to lock it (and then do a comparison).

So you can just remove expired weak pointers. The arguments of Remove is useless.

(*) either that OR you have a very serious double bug of double ownership of the object being destroyed!

curiousguy
  • 8,038
  • 2
  • 40
  • 58