Why Should I Not Try to Use "This" Value After "Delete This"

Why should I not try to use this value after delete this ?

The reason that you cannot do anything with a pointer after you delete it (this, or any other pointer), is that the hardware could (and some older machines did) trap trying to load an invalid memory address into a register. Even though it may be fine on all modern hardware, the standard says that the only thing that you can do to a invalid pointer (uninitialized or deleted), is to assign to it (either NULL, or from another valid pointer).

Return value after delete this;

I searched in draft for current standard and also read the question referenced in comments and the FAQ.

I could not find any elements saying that this code should lead to Undefined Behaviour.

The standard says :

• the value of the operand of delete may be a null pointer
  value, a pointer to a non-array object created by a previous new-expression : fine this is correct in above code
• If the value of the operand of the delete-expression is not a null pointer value, the delete-expression will
  invoke the destructor (if any) for the object : fine, destructor does nothing ...
• If the value of the operand of the delete-expression is not a null pointer value, then:
  If the allocation call for the new-expression for the object to be deleted was not omitted and the
  allocation was not extended (5.3.4), the delete-expression shall call a deallocation function : fine, object will be deallocated

As the code in not in the allocated part of object and as after delete this, code only uses the constant value true, there is no reason for the code to lead to UB. FAQ (and answers to ref^ed question) clearly indicates that delete this is valid and idiomatic C++.

So there is no reason why return true should not be executed.

That being said, as for any other usage of delete this programmer must ensure to use it only on objects allocated with new because if not it is indeed UB.

Is the pointer guaranteed to preserve its value after `delete` in C++?

No, it's not guaranteed and an implementation may legitimately assign zero to an lvalue operand to delete.

Bjarne Stroustrup had hoped that implementations would choose to do this, but not many do.

http://www.stroustrup.com/bs_faq2.html#delete-zero

C++ after delete pointer

int* ptr = new int(6); reserves some memory where ptr will be pointing to, that memory will be good to store one int, 6 or any other, it cannot be used to do anything else, you can reliably store the data there and access it later.

After you delete it you tell the system that the memory is available and the program can use it for whatever else it wants. ptr may still be pointing to the same address(the value of the pointer) and you can still print it, but that memory no longer belongs to ptr, accessing that memory through it (e.g.: dereferencing the pointer), amounts to undefined behavior.

The value of the pointer(which is the address it's pointing to) normally remains unchanged until you change it yourself.

A somewhat common practise is to assign nullptr to a pointer that doesn't point to any valid memory location, that way you can easily check if it can be dereferenced or not.

Values still accessible after I call delete, c++

If I call delete shouldn't the memory on heap be delete and when print is called not output anything for BankAccount?

No.

Deleting the object at that location in memory means it does not exist any more, so you're not allowed to access it.

It does not mean your program will magically print "nothingness" to protect you from this mistake.

Your program therefore has undefined behaviour; you must make sure you do not dereference an invalid pointer!

What happens to the pointer itself after delete?

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

Is it good practice to NULL a pointer after deleting it?

Setting a pointer to 0 (which is "null" in standard C++, the NULL define from C is somewhat different) avoids crashes on double deletes.

Consider the following:

Foo* foo = 0; // Sets the pointer to 0 (C++ NULL)
delete foo; // Won't do anything

Whereas:

Foo* foo = new Foo();
delete foo; // Deletes the object
delete foo; // Undefined behavior 

In other words, if you don't set deleted pointers to 0, you will get into trouble if you're doing double deletes. An argument against setting pointers to 0 after delete would be that doing so just masks double delete bugs and leaves them unhandled.

It's best to not have double delete bugs, obviously, but depending on ownership semantics and object lifecycles, this can be hard to achieve in practice. I prefer a masked double delete bug over UB.

Finally, a sidenote regarding managing object allocation, I suggest you take a look at std::unique_ptr for strict/singular ownership, std::shared_ptr for shared ownership, or another smart pointer implementation, depending on your needs.

cakephp use record values in afterDelete

private $deletedUserId;

public function beforeDelete($event, $entity, $options) {
    $this->deletedUserId = $entity->user_id;
}

public function afterDelete( ) {
    $user = $this->Users->get($this->deletedUserId);
    $user->set('active', false);
    $this->Users->save($user);
}

c++ delete pointer and then access the value of it points to

You first leaked a pointer

int *p = new int;
p = #  // You just leaked the above int

then illegally deleted something you did not new

delete p;  // p points to num, which you did not new

delete a.x vs a.x = undefined

They are not equivalent. The main difference is that setting

a.x = undefined

means that a.hasOwnProperty("x") will still return true, and therefore, it will still show up in a for in loop, and in Object.keys(). Whereas

delete a.x

means that a.hasOwnProperty("x") will return false

You can't tell if a property exists by testing

if (a.x === undefined)

If you are trying to determine if a property exists, you should always use

// If you want inherited properties
if ('x' in a)

// If you don't want inherited properties
if (a.hasOwnProperty('x'))

Following the prototype chain (mentioned by zzzzBov) Calling delete will allow it to go up the prototype chain, whereas setting the value to undefined will not look for the property in the chained prototypes

var obj = {
  x: "fromPrototype"
};
var extended = Object.create(obj);
extended.x = "overriding";
console.log(extended.x); // overriding
extended.x = undefined;
console.log(extended.x); // undefined
delete extended.x;
console.log(extended.x); // fromPrototype