It’s undefined behavior, so anything can happen. Quote from the standard [expr.delete]: In the first alternative (delete object), if the static type of the object to be deleted is different from its dynamic type, the static type shall be a base class of the dynamic type of the object to be deleted and the static … Read more
It looks like we can find a rationale for this change in defect report 348, which says: Specifically, standard says in 5.3.5 [expr.delete] paragraph 2: …if the value of the operand of delete is the null pointer the operation has no effect. Standard doesn’t specify term “has no effect”. It is not clear from this … Read more
The destructor of a variable with automatic storage duration (i.e. a local variable) would need to run when the variable’s lifetime ends. If there is no accessible destructor the compiler refuses to compile the code that allocates such a variable. Basically the distinction between “stack allocation” (an inaccurate choice of term by the way) and … Read more
You delete [] when you newed an array type, and delete when you didn’t. Examples: typedef int int_array[10]; int* a = new int; int* b = new int[10]; int* c = new int_array; delete a; delete[] b; delete[] c; // this is a must! even if the new-line didn’t use [].
It’s undefined behavior serious (it could work, it could crash, it could do something else).
It’s time to learn what undefined behavior is. 🙂 In C++, when you do something illegal/nonsensical/bad/etc. the standard often says that “it leads to undefined behavior.” This means that from that point forward, the state of your program is completely non-guaranteed, and anything could happen. At the point where you do your last *(pTest), you … Read more
This works for me in MSVC10 int x = 5; auto del = [](int * p) { std::cout << “Deleting x, value is : ” << *p; }; std::unique_ptr<int, decltype(del)> px(&x, del); And on gcc 4.5, here I’ll skip going to the standard, unless you don’t think that example is doing exactly what you’d expect … Read more
operator delete is unique in being a non-member or static member function that is dynamically dispatched. A type with a virtual destructor performs the call to its own delete from the most derived destructor. struct abc { virtual ~abc() = 0; }; struct d : abc { operator delete() { std::cout << “goodbye\n”; } }; … Read more
This is undefined behaviour, as there’s no way to reliably prove that memory behind the pointer was allocated correctly (i.e. by new for delete or new[] for delete[]). It’s your job to ensure things like that don’t happen. It’s simple when you use right tools, namely smart pointers. Whenever you say delete, you’re doing it … Read more
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, … Read more