3

I have an object, and have many pointers referring to it. In different places it can be deleted, but once in one place it is deleted, other places should be aware of the deletion. So they should check if the object already not deleted, then delete. Is there a smart pointer that can do the job?

Narek
  • 38,779
  • 79
  • 233
  • 389
  • 1
    Check out this question: http://stackoverflow.com/questions/94227/smart-pointers-or-who-owns-you-baby – rubikonx9 Apr 29 '15 at 10:37
  • I'm not entirely sure on its usage but it sounds like `std::weak_ptr` may be relevant for you – Kvothe Apr 29 '15 at 10:38

3 Answers3

6

std::shared_ptr can do this, along with std::weak_ptr

I will let you google the syntax yourself, but basically, an object held by a shared_ptr is deleted when the last shared_ptr goes out of scope, and any weak ptrs to it are able to detect this and stop working.

Andy Newman
  • 1,178
  • 2
  • 8
  • 23
  • That would do the trick. To use a weak ptr you basically cast it to a shared ptr first, and the cast will fail if it was been destroyed. The syntax is annoyingly long winded, but it does work. I generally find that I don't need weak ones very often - when they show up they often reflect a circular dependency and I avoid having those when I can. – Andy Newman Apr 29 '15 at 10:42
  • 1
    Also I don't want one pointer have some "advantage" over another such as one is the owner and others are observers. All pointers in my case are equivalent. – Narek Apr 29 '15 at 10:45
  • Then you will have to use shared_ptr for all of 'em, as far as I do understand them. When using one shared_ptr and for the rest of the pointers only weak_ptr ... those weak_ptr would become invalid, as soon as the shared_ptr gets destroyed. – Mr.Yellow Apr 29 '15 at 10:47
  • The shared_ptr approach is usually that objects are not destroyed until no one is using them anymore, which is safe and easy, but does mean you are not explicitly saying "die" to the object. If you really need to kill the object explicitly, and don't know which pointer you will be using to do it, you could also consider having a "zombie" flag on the object? I don't think a smart pointer exists with exactly those semantics. – Andy Newman Apr 29 '15 at 10:49
  • If the others are owners and not observers, it should not be possible for the object to be deleted whilst they are still holding a reference to it. – Puppy Apr 29 '15 at 10:56
  • @Puppy why each one can be an observer and and owner at the same time, no? – Narek Apr 29 '15 at 10:58
  • @Narek: No, they absolutely cannot. The two concepts are completely mutually exclusive. – Puppy Apr 29 '15 at 11:02
  • I'm not convinced that they are mutually exclusive - I think I could create a pointer that does what is being asked for here. In fact, I think I could implement it in terms of the existing pointers. I'm not going to because I have no use for it and think it's a bad idea, but it isn't conceptually impossible. It wouldn't be thread safe. – Andy Newman Apr 29 '15 at 11:19
  • Just because it can be written does not mean that it does not violate the relevant concepts. You could write a class whose operator++ simply prints to the screen, but that would not make it an iterator. – Puppy Apr 30 '15 at 20:03
2

Long ago in a game I worked on, well before C++ standard introduced smart pointers beyond auto_ptr, we had something similar - NotadPointer<T>. Null On Target Destruction Pointer.

It was a smart pointer of sorts which automagically nulled out any other pointers to the object when the object was delete'd.

It did this by maintaining a linked-list of all instances of pointers and then walking this list on destruction nulling out all of them. Pre-multithreading it was actually pretty neat and worked well [moderately expensive to copy/create but no overhead to actually dereference. Size of an instance was 3 pointers [prev/next/actual value].

However, in the brave new(ish) world of multithreading its dangerous - nulling out other pointers which are currently in use on another thread doesn't work out well so we abandoned it for shared_ptr like things and friends which are multithreading friendly.

Mike Vine
  • 9,468
  • 25
  • 44
1

Given your comments, I am inclined to believe that your concept of ownership is wrong.

The definition of an owner is that the object can't be destroyed whilst it's holding a reference. In your system though they are all owners and observers simultaneously, which is completely broken.

In the C++ ownership model, an object A owns resource B (including another object) if and only if resource B cannot be destroyed until A agrees. Otherwise, it is an observer. An object cannot be an owner and also have someone else destroy the object whilst it's still trying to use it. That is not an owner. Furthermore, an observer cannot destroy a resource, because it is not an owner. Only owners of a resource can destroy it.

An object cannot be both an owner and an observer simultaneously (of the same resource). That makes absolutely no sense at all.

If you want to share ownership, use shared_ptr which will handle deleting the object appropriately for you. If you want to observe whether or not it has been deleted, use weak_ptr. Do not ever delete the object under any circumstances except when shared_ptr automatically cleans it up.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • Thanks for the explanation, but I think what I want is a weak ownership. When you know when anywhere it is deleted, but also you can be the once who deletes. This should be a new type of ownership, right? I.e. owners are aware of each-other and they trust each-other as well, so that each owner can decide solely to delete or no. – Narek Apr 29 '15 at 11:12
  • @Narek: No, that's not a new type of ownership. It's a bad idea and definitely not ownership. – Puppy Apr 29 '15 at 15:39