0

Let's say I have a temp pointer to a Student object (doesn't matter what the definition of Student is - let's say it contains no pointer data members), which I'm using as follows : 

int main(){
Student *temp;
Student *s1 = new s1("John", 21);
Student *s2 = new s2("Jane", 23);
//do whatever;
temp = s1;
s1 = s2;
s2 = temp;

delete s1;
delete s2;

return 0;
}

Since I used new for s1 and s2, I know the objects are created in the heap, and I need to use the delete operator to get rid of them. My question is - do I need to "delete temp"? If not, why? How is "temp's" memory managed? Could someone explain how the memory manager handles this pointer, and what happens to it when it goes out of scope?

Yu Hao
  • 119,891
  • 44
  • 235
  • 294
aspen100
  • 965
  • 11
  • 22
  • 1
    Unrelated: What is `delete s1, s2`? – David G Nov 18 '13 at 00:03
  • 1
    1. What object does `temp` point to? 2. Did you already delete that object through a different pointer? Answer both of those and you should know the answer to your question. – WhozCraig Nov 18 '13 at 00:06

3 Answers3

4

First of all, you can't delete 2 objects with the same delete, so this doesn't work:

delete s1, s2;

That just deletes the object pointed to by s1, and does nothing to s2 (see: the comma operator). Change it to 2 separate statements.

With that out of the way, no you do not have to call delete on temp, because the object it pointed to (the same one s2 pointed to) is already destroyed and deallocated with the call:

delete s2;

You can, however, call delete temp; instead of delete s2;, since they both point to the same object. You could even do this:

delete temp;
temp = s1;
delete temp;

delete works on objects allocated with new, via the pointers that point to them. It doesn't matter which pointer you call delete on. It only matters which address is stored in the pointer when you call it. And that address must be one which was previously returned by new, but which hasn't already been deleted.

As for this:

Could someone explain how the memory manager handles this pointer, and what happens to it when it goes out of scope?

Nothing happens when a pointer goes out of scope. At least, nothing that doesn't happen to a regular variable like an int or a char, perhaps a stack pointer gets moved, but that's an implementation detail.

Benjamin Lindley
  • 101,917
  • 9
  • 204
  • 274
  • 1
    @srihari pay special attention to the words **"instead of"** in that closing sentence. It is fundamental to your question. – WhozCraig Nov 18 '13 at 00:14
2

You don't have to delete temp as this was just a copy of the pointer, since you are deleting the actual allocated buffers. It is an auto variable which will be deleted once it goes out of scope.

If your class Student overrides the assignment operator to make a copy, then either you could delete the variable explicitly or shall be deleted once the function returns.

Ganesh
  • 5,880
  • 2
  • 36
  • 54
  • I don't quite understand the second part - do you mean doing a deep copy? If so, wouldn't temp point to a copy of the object pointed to by `s1` in the heap? In that case, wouldn't I have to call `delete temp` explicitly? How will it get deleted when the function returns? – aspen100 Nov 18 '13 at 00:13
  • @Srihari.. Please refer to this link which I feel is a very informative on the subject of calling `delete` http://stackoverflow.com/questions/10081429/when-is-a-c-destructor-called . Of course, it is definitely a good practice to explicitly call a `delete`, but this is more attributed to `C` programmers than `C++` ones. – Ganesh Nov 18 '13 at 00:23
1

I think I've got it - temp is just an integer on the stack, and will be handled by the memory manager once it goes out of scope, like any stack variable.

temp and s1 now point to the same memory location : hence, deleting s1 takes care of the object temp is pointing to. There will be no memory leaks because of temp, at this stage. However, if I try to access temp, after the delete s1; statement, my program will probably crash.

aspen100
  • 965
  • 11
  • 22
  • 1
    Note: `temp` is not "an integer on the stack". It is a pointer, the representation of which is implementation-dependant and you don't necessarily know. The rest of your answer is entirely accurate, and it sounds like you understand. +1 (and consider up-voting other helpful answers). – WhozCraig Nov 18 '13 at 00:18
  • @WhozCraig : My understanding was that pointers are simply intended to store memory addresses, which in turn are just integers in hexadecimal representation...how _else_ could a pointer be stored? If it is not always stored as an integer, do we need to know how a pointer is implemented before doing pointer arithmetic (for ex., ptr++)? (+1 for bringing this up, I didn't know pointers weren't always implemented as integers. :) – aspen100 Nov 18 '13 at 00:44
  • The very term "address" is implementation dependent. And the point is *you don't have to know what "it" actually is* so long as you follow the rules of the standard. There are some *amazing* platforms that do things with their implementation of pointers and addresses that would boggle most minds (AS/400 is one of them). – WhozCraig Nov 18 '13 at 00:48
  • 1
    It should also be noted that the hexadecimal representation you are used to seeing is just how your `ostream` or `printf` implementers chose to display them. It has nothing to do with their actual storage, which is in binary just like everything else. – Benjamin Lindley Nov 18 '13 at 00:51