Firstly, what is happening here is undefined behaviour. This means that literally anything can happen when you run the code, even apparently correct/reasonable behaviour

In your latest example, the allocator has requested memory from the OS, but as an optimisation it does not immediately release it when you called delete, figuring that most applications will have a fresh memory request coming in pretty soon (that and it has probably allocated some memory in that page anyway, preventing it from being released yet).

This means that nothing has really happened except that the allocator has marked the memory (somewhere in its internal data) as "available for allocation". If you had a thread running in the background, or inserted another function call, you might find the memory has been overwritten because some other part of your program is now using it.

This is where you get memory corruption, hat memory you wrote to could potentially be used by unrelated data.

And you didn't allocate on the stack in your latest program. Both new/delete control the heap (or the free store, which is almost the same thing really, just one is managed by malloc/free and the other by new/delete).

m_integer is allocated where the enclosing SomeClass instance is allocated, here this is the heap.

Quote:
Thank you for the explanation, compiler should really give a warning or something cause I think this kind of behavior can lead to subtile bugs...

Certainly that would be nice. But this is deemed too expensive, this is the cost of using a low level language.

On the bright side, by consistently using RAII objects, standard containers and smart pointers you can all but eliminate manual memory management (or at least contain it to a small part of your code). This reduces the scope for such bugs.