How does std::unique_ptr handle raw pointers/references in a class?

Question

Let's say I have a class A with the following definition:

class A {
  A(std::string& s) : text_(s) {}

 private:
  std::string& text;
}

Note that A contains a reference to a string object. This can be because we don't want to copy or move the object.

Now, if I have the following code

std::string text = "......";
std::unique_ptr<A>(new A(text));
// now I destroy text in some way, either explicitly call the deconstructor or it goes out of scope somehow

The question is what happens now to the unique_ptr's object A? The A contained a reference to the object text which is deleted. Does unique_ptr's A have now a dangling pointer? Or does unique_ptr handle this case and extend the lifetime of the object for which it contains a raw pointer?

I'm guessing you have a background with a more high level language than C++ — StoryTeller - Unslander Monica, Dec 13 '21 at 16:09
`std::unique_ptr(A(text);` is missing a bunch of characters, and isn't how you initialise a unique pointer. — Caleth, Dec 13 '21 at 16:10
You're not deleting the string, you're destroying it, which will cause much grief when it is automatically destroyed again later. It is the same awfulness as if you had `std::string text; text.~string();` — molbdnilo, Dec 13 '21 at 16:11
Calling the destructor of `text` explicitly yanks the rug out from under the rest of your code. The `unique_ptr` isn't really relevant here. The reference in the `A` object is no longer valid, so any use of it will result in undefined behavior. And when the destructor for `text` is run automatically at the end of it scope, the result is, at best, unpredictable. Don't do that. — Pete Becker, Dec 13 '21 at 16:13
please make the example working. In general, if you do what it looks like you want to do, you'll be double deleting. see https://stackoverflow.com/questions/9169774/what-happens-in-a-double-delete — Reinhold, Dec 13 '21 at 16:13
`std::unique_ptr` doesn't prevent dangling references inside the object it manages — Jarod42, Dec 13 '21 at 16:14
There is no "magic" inside `unique_ptr`. It works exactly like any other (dynamic) object creation and destruction. — molbdnilo, Dec 13 '21 at 16:15
Thanks for your comments. I corrected the code, I do not create about how to destroy the object. he point is it goes out of the scope somehow and gets destroyed. This is just a toy example so that you don't have to look at hundreds of lines of code. — Berkay Berabi, Dec 13 '21 at 16:17
You still don't have a `unique_ptr` that outlives the `text` in whichever scope this is. You have an unnamed temporary that ceases to exist at the `;` — Caleth, Dec 13 '21 at 16:18
`std::shared_ptr` handles that case. There is also a `std::weak_ptr` which is useful if you just want to detect when object is deleted, not necessarily extend its lifetime. — Aykhan Hagverdili, Dec 13 '21 at 16:19
@AyxanHaqverdili shared pointer doesn't handle the case where you have a reference data member bound to a dead object — Caleth, Dec 13 '21 at 16:20
@Caleth You're supposed to store a shared_ptr, not a reference. I thought that was obvious. — Aykhan Hagverdili, Dec 13 '21 at 16:21
@AyxanHaqverdili still doesn't help you when the initial object is automatic duration. — Caleth, Dec 13 '21 at 16:22
It seems the answer to my question is that std::unique_ptr does not extend the life time of a raw pointer inside a class that it contains. So, in my case I would have a dangling pointer in my classes member variable. I have to make sure myself that the objects have to right lifetimes. Am I right? @Caleth — Berkay Berabi, Dec 13 '21 at 16:23
@BerkayBerabi Your question asks about `raw pointers`, yet you use a `reference`. That alone is dangerous. — Raildex, Dec 13 '21 at 16:23
@Caleth yes, you create the initial object with make_shared to make that work. Maybe you should shed some light on that use case in your answer :) — Aykhan Hagverdili, Dec 13 '21 at 16:24
@BerkayBerabi all that `std::unique_ptr` does is call `delete` on the pointer it holds in it's destructor. Pointers and references can become invalid, you have to care about the lifetime of the referent. — Caleth, Dec 13 '21 at 16:25
@Raildex yes, thank you I updated the title of the question. For my question, it does not matter if it is a raw pointer or reference. Both provide the same concept and the problem. — Berkay Berabi, Dec 13 '21 at 16:28
Continued comments make seem like OP was taught that `std::unique_ptr` was some kind of C++ magic. `A` needs to handle its own business, and `std::unique_ptr` will ensure that the heap-allocated `A` is handled. It's classic separation of concerns. If you screw up `A`, `std::unique_ptr` won't save you. — sweenish, Dec 13 '21 at 16:31
I mean the other guy comes here telling me this is bad code design. Like seriously? Of course, it is a bad design. Who would write code like that? I was just trying to produce a minimal example that illustrates the concept. We should focus on the question, not something else — Berkay Berabi, Dec 13 '21 at 16:36

score 2 · Accepted Answer · answered Dec 13 '21 at 16:17

C++ is not a safe language. If you have a pointer or reference to an object that is destroyed, using that pointer or reference is a bug.

Assuming you actually construct an A that outlives text, it will still reference the destroyed object, and any use of that member is undefined behaviour.

How does std::unique_ptr handle raw pointers/references in a class?

1 Answers1