Printable View
When we invoke the delete operator, will both the objects (the memory that contains the variables) and the pointer itself be deleted?
For example
0x71233333=> Name : Jack
Phone: 72882222
After the delete would it become
0x00000000=> Name: NULL
Phone: 0
If not, that means we manually reset the value of the pointer to NULL, however, will the memory that stores the pointer be reclaimed?
Thanks
Jack
Read Stroustrup's answer to the FAQ: Why doesn't delete zero out its operand?Quote:
Originally Posted by lucky6969b
Also, the memory that the pointer points to is not guaranteed to be zeroed.
It's all very simple really. There are two kinds of memory only:Quote:
Originally Posted by lucky6969b
1. Memory that's automatically reclaimed when it goes out of scope (cannot be reached from anywhere anymore). In this category there's static memory which is available for the whole duration of a program, and automatic memory also called stack memory which is available during a function or method call.
2. Memory that's given back by the programmer using delete. It's called free store memory or heap memory and it's available after allocation by the use of new.
Never is this a question about "nulling" memory. It's about whether memory is available for use by the programmer or is in the hands of the runtime system. It can be one or the other only. Many "memory violation" bugs are related to this. It's when programmers use memory that's owned by the runtime system.
Couldn't you just write a little program and see what happens?Quote:
Originally Posted by lucky6969b
That's not a good idea and never was.Quote:
Originally Posted by GCDEF
Observing a language implementation is close to useless. You'll never know if a finding is defined or accidental. The only way to know for sure how a language "works" is to study the language specification.
I think that it is a good idea here. The question is posed as "Will this happen?" Rather, it should be posed as: "This happened. Why, and is this behaviour well defined?"Quote:
Originally Posted by nuzzle
The act of writing the test program and trying to figure out why the results are what they are will help in the learning process. It is okay to be wrong at this point...
... the problem comes if after you test, you assume that the behaviour you got is well defined, and then go on to expect the same thing to happen for similiar situations.Quote:
Originally Posted by nuzzle
I don't agree in this case. He asked if after delete, a pointer becomes NULL. That seems easy enough to check by writing code and seeing what happens.Quote:
Originally Posted by nuzzle
Yeah, that is why I say that this should have been tried first and then the question posed differently. The catch is that even if the pointer becomes a null pointer after you use delete on it, concluding that this is guaranteed behaviour would be a mistake.Quote:
Originally Posted by GCDEF
Correct. Sometimes trying is good, but that only shows specific behaviour in a specific case.
the pointer switching to null could be the spec.
Or it could be a special case.
or it could be how this particular compiler does it with the specific compile settings that were used.
or it could be coincidence. The spec might have simply stated "the pointer after a delete could be any value) and it just happened to be 0 because of how the compiler worked in that one example.
He could just as well have asked what the result was of:
int a = 0;
int b = min(a++,a++);
and made conclusions out of that, when the actual spec says something like this is undefined.
The answer is simple.
deleting a pointer will free the memory and return it to the free store.
The memory pointed too may or may not still hold the same information after the delete. Any pointers or references you still hold to that memory are to be considered in an undefined state.
Deleting a pointer does not guarantee the pointer is set to null. It does not even guarantee that the pointer still holds the same value after the delete.
you can reuse a pointer variable after a delete and assign a value to it.
This only works if the code is correct. Only then can it be used to draw any conclusions about the language definition. This is a tautology. To know what's correct you must know what's correct.Quote:
Originally Posted by GCDEF
And that's why it's a bad suggestion. It requires struggling newbies to write error-free code in the first place. Not even seasoned programmers can guarantee that. At least I can't.
No one suggested to draw conclusions based on the observed behavior of a sample program alone. However, what you seem to be suggesting is the opposite: not to write a sample program and to only learn by reading the standard (or any other material explaining it). That goes against decades of research into how people learn. You cannot learn new ideas from definitions and explanations alone. You need to see (or should I say, 'experience') examples and counter-examples of a new idea in order to form the neural structures that will allow you to be able to understand and remember a new idea. Concretely that means writing small test programs and running them in the debugger to see what happens. I fully agree that this is not enough to learn; reading authoritative material is required as well. But I'd say that writing test programs and running them (in the debugger, not in your head) is almost always necessary to gain a good understanding.Quote:
Originally Posted by nuzzle
Good grief. He just asked if a pointer is set to NULL automatically after a call to delete. All that's required to test that is two lines of code. If he can't get that right, the answer won't matter anyway.Quote:
Originally Posted by nuzzle
That still wouldn't be a guaranteed answer.Quote:
Originally Posted by GCDEF
Supposed he had tested it, and on his compiler with his compiler settings and library it did indeed set it to NULL. That still wouldn't be enough to conclude that this is part of the standard or specific behaviour of his runtime/compiler/compile settings.
Now in this particular case it would have worked because the way the standard is defined, there is no way to modify the pointer as the argument to delete is an rvalue, and as a result delete can't change the pointer. But it can't be used as a general solution to question asked.
Now had the answer to the OP been "Try it out, there is only one way this can work according to the standard" or something similar, then maybe... Telling someone to try it out is only a good answer if you know that the result will always guaranteed be the same on all compilers whatever the settings or library, and only if you tell the asker that there is only one answer, but without knowing the standard, you can't know for sure that the result will always be guaranteed or just a specific case result.
Are you sure? Stroustrup contradicts your claim in the FAQ that I linked to in post #2, though it could be that the FAQ answer is outdated. A quick check of the standard does not confirm or deny it, but maybe that requirement is stated outside of C++11 Clause 5.3.5.Quote:
Originally Posted by OReubens