Public Group

# pointer problem

This topic is 4157 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

    int *tempOne;
int *fNum;

int x = 15;

tempOne = &x;
fNum = tempOne;

cout << endl;

cout << "before delete " << *tempOne << endl;

delete tempOne;

cout << "after delete " << *tempOne << endl; /* i see the number 15 meaning i didnt delete tempOne*/

// If delete should delete a pointer why can that same pointer output a previous variable?


##### Share on other sites
Delete can only be called on pointers to objects allocated with new. I don't know what you expected to see in this example (its actual behavior is undefined; you delete a non-new'd pointer and attempt to access it after deletion), but you need to re-read whatever section of whatever book you read which covered pointers.

##### Share on other sites
You seem a little confused. You don't need to delete every pointer you create. In fact, doing so would cause you a lot of trouble. I'm surprised that snippet even runs.

The rule of thumb is that each instance of new should be matched with a delete. Since the pointer in that code was created by referencing a variable, it shouldn't be deleted.

Now, I'm going to post something before you do:

int *px = new int;*px = 5;cout << *px; // Outputs '5'delete px;cout << *px; // Still outputs '5'!
This would probably fail (crash or assert) in a debug build, but may work fine in release. Note that I have an instance of new so the use of delete is kosher. Yet it still looks like px isn't properly being deleted. What gives?

Well, px is being deleted, but you are still accessing its residual memory. The second cout command dereferences a dangling pointer, which, according to the standard, causes undefined behaviour. So you should never actually do this, and indeed the code I just wrote is bad code, but nevertheless it compiles and often runs.
To understand why you still get the '5', you have to understand how the operating system allocates memory. Just as you'd imagine, the RAM in your machine is fairly static: it's always there and it certainly isn't being manufactured or destroyed inside the machine. So when you invoke new, it doesn't 'create' memory, but it finds an unused piece and reserves & commits it, so that nothing else will use it. You use this memory, via its pointer, until you've finished with it, when you delete it. Now, the memory isn't 'destroyed' so much as deallocated. That is to say that the operating system throws it into the 'unused' pool so that it doesn't belong to your code anymore. Since nobody ever uses memory without initialising it, there is nothing to gain from clearing it, so the OS leaves it filled with whatever was there when you trashed it; in this case, '5'. So when you later dereference the deleted (and invalid) pointer, your access violation may well slip through the net and you get the 5 back.

So I guess the bottom line is that checking a pointer's value isn't a very good way of telling if it has been deleted. At best, you'll raise an exception. At worst, you'll end up with what you expected. Another day, you'll get '666' out. Just trust the compiler about its memory management and it will treat you fairly in return. And certainly don't attempt to dereference dangling pointers.

• 37
• 12
• 10
• 10
• 9
• ### Forum Statistics

• Total Topics
631362
• Total Posts
2999571
×