1

I have a pointer to an abstract class object ptr1. I need to create another pointer with the same adress ptr2 so that when you free and zero the ptr1 pointer, the ptr2 also becomes zero.

SomeObject* ptr1 = new SomeObject();
SomeObject* ptr2 = ptr1;

delete ptr1;
ptr1 = nullptr; // after that ptr2 should be nullptr

I know that it's dangling pointers problem and it can be solved with smart pointers but I want to solve it without them. Thanks in advance for your help!

curiousguy
  • 8,038
  • 2
  • 40
  • 58
Egor
  • 107
  • 1
  • 8

1 Answers1

3

Declare ptr2as a reference or pointer to ptr1, i.e. one of the following:

SomeObject* &ptr2 = ptr1;

SomeObject** ptr2 = &ptr1;

By only having one instance of the pointer and ensure that this is only passed around by references or pointers to the pointer instance, you ensure that there cannot exist outdated copies of the pointer.

nielsen
  • 5,641
  • 10
  • 27
  • 1
    Or, alternately, `SomeObject** ptr2=&ptr1;` Then `*ptr2 == nullptr` can be tested. I prefer your use of a reference but the OP asked to create a pointer to test and a reference isn't an object but more of an alias. – doug Sep 22 '19 at 17:54
  • What if the `ptr2` is a class field that is not initialized in the constructor? – Egor Sep 22 '19 at 17:55
  • @Egor Then use a pointer to the pointer, i.e. `SomeObject **ptr2 = &ptr1;` as @doug mentions (thanks). I have added this to the answer. – nielsen Sep 22 '19 at 17:56
  • 1
    @Egor It seems you are looking for 2 star points (`T**`). Generally, the more stars you need to express your type, the strong the hint that you should consider whether your design is going in the right direction. `T**` isn't catastrophic, but still, it's a sign you might want to keep an eye out for a simpler and clearer solution. – François Andrieux Sep 22 '19 at 18:03
  • One `*` comes from abstract class. Second `*` it's seems the only solution – Egor Sep 22 '19 at 18:05
  • @Egor The proper solution is smart pointers, as you already know. (You'd use a `weak_ptr` here) Not sure why you've discarded the correct, proper solution, and insist on making life as hard as possible. – Lightness Races in Orbit Sep 22 '19 at 18:08
  • @LightnessRacesinOrbit In this as in many other cases you cannot say that something is **the** correct solution without knowing the circumstances. For example, smart pointers comes at a [price](https://stackoverflow.com/questions/22295665/how-much-is-the-overhead-of-smart-pointers-compared-to-normal-pointers-in-c) which is usually acceptable, but may be a problem in special situations. Hence asking for increased pointer safety without involving smart pointers is a completely legitimate question. – nielsen Sep 22 '19 at 18:17
  • 2
    @nielsen I'm not saying it isn't a completely legitimate question, but without actually knowing what that context you mention _is_, it's not a very useful one. In the absence of any other constraints, a weak_ptr is the go-to solution for this use case. This is literally what they were invented for. Your suggestion - while the right answer to this question, well done - introduces safety problems such as risk of another dangling pointer. – Lightness Races in Orbit Sep 22 '19 at 18:19
  • @LightnessRacesinOrbit It is a weird question. I have difficulty imagining a use case for it. It would be good if the OP fleshed out her thinking on how this could be used. – doug Sep 22 '19 at 19:12
  • @doug While Light has a good point that smart pointers is the "default" solution, there are exceptions. As I mentioned above, smart pointers come at a price. Just look at this [allocation with smart pointer](https://godbolt.org/z/a8KRvR) versus this [plain allocation](https://godbolt.org/z/FPCCk2). Sometimes this matters. – nielsen Sep 23 '19 at 06:26
  • And sometimes (most of the time) t doesn't :) – Lightness Races in Orbit Sep 23 '19 at 10:17