Back to basics (Part II) - the delete operator
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Results 1 to 14 of 14

Thread: Back to basics (Part II) - the delete operator

  1. #1
    Join Date
    Dec 2010
    Posts
    587

    Back to basics (Part II) - the delete operator

    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

  2. #2
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,249

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by lucky6969b
    When we invoke the delete operator, will both the objects (the memory that contains the variables) and the pointer itself be deleted?
    Read Stroustrup's answer to the FAQ: Why doesn't delete zero out its operand?

    Also, the memory that the pointer points to is not guaranteed to be zeroed.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  3. #3
    Join Date
    May 2009
    Posts
    2,413

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by lucky6969b View Post
    If not, that means we manually reset the value of the pointer to NULL, however, will the memory that stores the pointer be reclaimed?
    It's all very simple really. There are two kinds of memory only:

    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.
    Last edited by nuzzle; September 13th, 2012 at 02:53 AM.

  4. #4
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    12,055

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by lucky6969b View Post
    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
    Couldn't you just write a little program and see what happens?

  5. #5
    Join Date
    May 2009
    Posts
    2,413

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by GCDEF View Post
    Couldn't you just write a little program and see what happens?
    That's not a good idea and never was.

    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.

  6. #6
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,249

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by nuzzle
    That's not a good idea and never was.
    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?"

    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...

    Quote Originally Posted by nuzzle
    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.
    ... 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.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  7. #7
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    12,055

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by nuzzle View Post
    That's not a good idea and never was.

    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 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.

  8. #8
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,249

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by GCDEF
    He asked if after delete, a pointer becomes NULL. That seems easy enough to check by writing code and seeing what happens.
    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.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

  9. #9
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,770

    Re: Back to basics (Part II) - the delete operator

    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.

  10. #10
    Join Date
    May 2009
    Posts
    2,413

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by GCDEF View Post
    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.
    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.

    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.

  11. #11
    Join Date
    Jul 2005
    Location
    Netherlands
    Posts
    2,012

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by nuzzle View Post
    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.

    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.
    Cheers, D Drmmr

    Please put [code][/code] tags around your code to preserve indentation and make it more readable.

    As long as man ascribes to himself what is merely a posibility, he will not work for the attainment of it. - P. D. Ouspensky

  12. #12
    GCDEF is offline Elite Member Power Poster
    Join Date
    Nov 2003
    Posts
    12,055

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by nuzzle View Post
    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.

    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.
    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.

  13. #13
    Join Date
    Apr 2000
    Location
    Belgium (Europe)
    Posts
    3,770

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by GCDEF View Post
    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.
    That still wouldn't be a guaranteed answer.
    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.

  14. #14
    Join Date
    Jan 2006
    Location
    Singapore
    Posts
    6,249

    Re: Back to basics (Part II) - the delete operator

    Quote Originally Posted by OReubens
    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.
    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.
    C + C++ Compiler: MinGW port of GCC
    Build + Version Control System: SCons + Bazaar

    Look up a C/C++ Reference and learn How To Ask Questions The Smart Way
    Kindly rate my posts if you found them useful

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Azure Activities Information Page

Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center