TransWikia.com

What makes a heap allocated object "referenced" in C++?

Stack Overflow Asked by AbdelRahman Mahmoud on November 10, 2021

What, in C++, determines that a heap allocated object to be referenced? In his book, Data Structures and Algorithm Analysis in C++, Mark Allen Weiss writes "When an object is allocated by new is no longer referenced, the delete operation must be applied to the object (through a pointer)" I find this sentence a bit confusing, all I understand is that a pointer holds a reference to a memory address, but how is the object that represents this address referenced by something else? And when that something else is no longer referencing it, I have to call delete?

4 Answers

The book is incorrect. There is no rule about "referencing" and delete. The rule is that you should delete objects allocated by new when you don't need them any more.

When the book says the object is "no longer referenced", it actually means the object is no longer needed. You must have at least one reference to the object, otherwise you can't even delete it!

"Referenced" means that your program knows the address of the object, because it's stored in a variable.

Answered by user253751 on November 10, 2021

Just to illustrate something like

int* a = new int;
int* b = a;

It would look like this:

+---
| a | --
+---+         +-----------------------+
          >--> | heap allocated memory |
+---+    /     +-----------------------+
| b | --/
+---+

Both of the pointers a and b are pointing to the exact same memory.

If you delete a after this then both a and b are invalidated.

Answered by Some programmer dude on November 10, 2021

how is the object that represents this address referenced by something else?

That means that something else in your program is holding a pointer (or a reference, which for our purposes amounts to the same thing) to the heap-allocated-object's memory location.

And when that something else is no longer referencing it, I have to call delete?

Well, you don't have to -- the alternative is to just forget about the object and never delete it at all, which is known as a memory leak. The only problem with that is that if you don't delete the object, the RAM (and any other resources) taken up by that object will never be released (at least not until your program exits), and if you keep leaking objects, eventually your computer will run out of RAM and grind to a halt. So for very short-lived programs it might be okay to be sloppy and not delete objects that are no longer referenced, but in general it's better to clean up after yourself.

Moreover, could you please tell me about sources I can read that would clarify the usage of memory in C++?

Any decent C++ book should have a section on it; in general the best practice is to use smart-pointers (like std::unique_ptr or std::shared_ptr) rather than plain old C-style pointers whenever you are working with heap-allocated objects. That way is much less error-prone, since you never have to figure out when is the correct time to call delete, since the pointer-class will automatically call delete for you at the correct time.

Answered by Jeremy Friesner on November 10, 2021

I wouldn't get too obsessed with the precise choice of language there. What he's trying to say is that if you allocate an object on the heap, it's your responsibility to de-allocate it when you're done with it. Otherwise, it will remain valid and waste memory.

You can be completely done with an object even though it's still referenced. And precisely when you remove all references to the object and when you de-allocate it is up to you. The point is simply that you definitely don't want to try to use it after you de-allocate and and you also don't want to fail to de-allocate a large number of objects over a long period of time and waste memory.

Fortunately, in modern C++, you have a number of tools to make this much easier including move semantics, unique_ptr, and many more.

Answered by David Schwartz on November 10, 2021

Add your own answers!

Ask a Question

Get help from others!

© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP