Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Deallocates the memory block pointed by ptr (if not null), releasing the storage space previously allocated to it by a call to operator new and rendering that pointer location invalid.

Please help to clear my confusions: what happens to the pointer itself after delete? The pointer itself does have an address, right? So after the pointed block is deleted, what about the pointer itself?

Could I say that the pointer itself will be free after returning the method where the pointer is initialized? Is the pointer itself placed on the stack or heap?

The pointer itself does have an address and the value. The address of the pointer does not change after you perform delete on it. The space allocated to the pointer variable itself remains in place until your program releases it (which it might never do, e.g. when the pointer is in the static storage area). The standard does not say what happens to the value of the pointer; all it says is that you are no longer allowed to use that value until you assign your pointer a valid value. This state of the pointer is called dangling .

In your program, the pointer ptr is dangling after delete has completed, but before the ptr = NULL assignment is performed. After that it becomes a NULL pointer.

The pointer it self is placed on stack or heap?

Pointer variable is a regular variable. Its placement follows the same rules as the placement of other variables, i.e. you can put a pointer in a static area, in an automatic area (commonly known as "the stack") or in the dynamic memory (also known as "the heap"). In this case, you allocate a pointer to a pointer:

TheObject **ptrPtr = new TheObject*; // The pointer to a pointer is on the stack
*ptrPtr = new TheObject;             // The pointer to TheObject is in the heap
delete *ptrPtr; // The space for TheObject is released; the space for the pointer to TheObject is not
delete ptrPtr;  // Now the space for the pointer to TheObject is released as well
// The space for the pointer to pointer gets released when ptrPtr goes out of scope
                "Neither of them changes when you perform a delete on the pointer" I don't think the standard provides such a guarantee.
– user541686
                May 13, 2014 at 2:14
                @dasblinkenlight If we create lots of pointers and then delete them, any chance we get "out of memory" since the pointer itself is not released?
– Stephen Kuo
                May 13, 2014 at 2:26
                @Stephen: You're allowed to assign a new value to the pointer, but you're not allowed read the old value. This is true for every pointer that had that old value, not just that particular pointer -- they are all invalidated when delete is called on the pointer.
– user541686
                May 13, 2014 at 3:21
                @dasblinkenlight: If reading a pointer is implementation-defined then that means it could trap on a particular implementation. So you can't rely on it without knowing the particular implementation, which we don't here.
– user541686
                May 13, 2014 at 21:02
In C and C++, a pointer can be thought of in many ways as just an integer in disguise. So when you say:
TheObject *ptr = new TheObject;
Then ptr is just like a stack-allocated ("automatic") integer variable, one that happens to be big enough to hold the memory address of the heap-allocated TheObject. It's similar to saying
size_t i = /* some value given to you by the runtime */.
Later on, when you write
ptr = NULL;
it has an identical meaning to:
i = 0;
So what happens to the pointer when you leave the function? Just as with any other automatic variable, it's deallocated at the end of the block. It's as simple as that. (Of course, the thing that's pointed to will live on until you call delete, or free() in C.)
Performing delete invalidates the pointer (see [new.delete.single]#10). It could be said that the value is changed: previously it had a value, but now it does not have a value. 
Trying to read the value of the pointer (note: this is different to dereferencing it) causes implementation-defined behaviour since C++14, which may include generating a runtime fault. (In C++11 and older standards, it was undefined behaviour). Ref: [basic.stc.dynamic.deallocation]#4.
It would be legal for the compiler to also set the pointer to be null, or set it to some recognizable garbage for debugging purposes (although I don't know of any compilers that do this).
                You can access the value of a pointer all the time, e.g write access with x = 0;. But you should only dereference the pointer only when it is valid. In that case you don't access not only the pointer (read access) but you will also access the value where the pointer points to. Could you improve your answer to make this clear?
– harper
                May 13, 2014 at 3:37
                of course reading *x is undefined, after x is deleted. Your answer is not clear, are you saying reading x or *x is undefined?
– PoweredByRice
                Apr 20, 2017 at 1:53
                @PoweredByRice reading x is implementation-defined. I hoped that saying "read the value of the pointer (note: this is different to dereferencing it)" makes that distinction clear
– M.M
                Apr 20, 2017 at 2:20
                @M.M "Trying to read the value of the pointer (note: this is different to dereferencing it) causes implementation-defined behaviour since C++14, which may include generating a runtime fault. (In C++11 it was undefined behaviour)." AFAIK there never was (and will be) UB with copying pointer values, deleted or not. You've seem to have posed som misconception with that: stackoverflow.com/questions/44182049/pointers-in-c-after-delete
– πάντα ῥεῖ
                May 25, 2017 at 14:06