Why I Can Access Member Functions Even After the Object Was Deleted

Why I can access member functions even after the object was deleted?

So, my question is, why I'm still able to call Go_XXX_Your_Self() and Identify_Your_Self() even after the object was deleted?

Because of undefined behavior.

Is this how it works in C++? (is there even after you delete it?)

Because of undefined behavior. There is no guarantee that it will work the same on other implementations. Again, undefined behavior.

Also can you check to see if it's not there? (I know theoretically is not possible but I'm curious to see what methods are out there)

delete MC1;
MC1 = nullptr;

By setting the pointer to nullptr after deleteing it, the runtime is most likely to detect that you are accessing an invalid, you-have-no-right-to-use location. Also, by diligently doing this for all applicable pointers, you have the ability to check if the object is valid or not (valid if non-nullptr).

if(my_ptr) {
   // my_ptr is most possibly valid (though you can still go wrong)
   // use my_ptr
}

Similarly, you should also set raw pointers to nullptr when they aren't yet initialized to some valid address.

MyClass* some_ptr = nullptr;
...

But again, if you have access to modern C++11 facilities, it's much better not to use raw pointers at all, and just use std::unique_ptr or std::shared_ptr (depending on your required semantics). And on future C++ standard revisions, you may also want to use the proposed std::exempt_ptr which is a non-owning, observe-only pointer wrapper.

Why can still access class instances after deleting them

If I can still access the instance members after I deleted it how do I know if it was properly deleted?

Just trust the runtime library: if you call delete, the thing is deleted, period. Once you tell the system that you no longer need the memory, you gave it up - it is no longer yours. The system counts it with its available memory to redistribute, so it can give it to other parts of your program upon request. You can still access that memory, and may even find what was there before you gave it up, but that's undefined behavior.

Is my code going to cause a memory leak?

No, because you release the memory that you allocated.

I guess the ultimate question is: am I doing something wrong?

Yes - accessing the memory of deallocated object is wrong (undefined behavior). Other than that, it looks fine.

After using 'delete this' in a member function I am able to access other member functions. Why?

Let's compare that to a similar szenario:

A *a= new A();  
func(a);  
delete a;  
func2(a);  

In my sample the compiler just passes the pointer a to func and func2, it does not care if it is pointing to a valid object. So if you call func2(a) and func2 dereferences the pointer, this is undefined behaviour. The program might crash if the memory was released back to the operating system and the program cannot access *a anymore. Normally delete keeps the memory allocated, does not pass it back to the operating system, so accessing *a after delete will not give an exception, but just return any value. This might be the previous values of *a, but it might also be any other value depending on the implementation of delete and depending on other calls to new done between delete a and *a. MSVC for example sets the memory to a predefined pattern in debug mode so you can easily spot when accessing freed memory.

Why is this related to your question? Because the compilers passes this as a hidden, implicit parameter.

Why can I run object's method after delete this pointer at second time call

My question is why we can run ptr->methodTest() at second time ?

It's undefined behaviour. The error can't be prevented by a compile-time check, since the compiler can't in general track the run-time lifetime of objects, and C++ usually doesn't impose the overhead of run-time checks.

It should coredump when calling ptr->methodTest() at second time immediately right ?

You might get a protection fault when the pointer is accessed. Simply calling a non-virtual member function typically doesn't access the object, so the error is likely to go undetected at that point. (And that's assuming that the memory is no longer accessible; in practice, the pointer will often still point to accessible memory, so even attempting to access the deleted object might go undetected).

---

Related Topics