Dear Peter

Actually out of memory will anyway terminate the program ( yes I am thinking about the **lazy memory allocation ** scheme use by many platforms )

———————- man malloc —————————

By default, Linux follows an  optimistic  memory  allocation  strategy. This  means  that  when malloc() returns non-NULL there is no guarantee that the memory really is available.
———————- man malloc —————————

AIX memory  allocation is also similar ( as are many other platforms as Herb Sutter mentions in one of his books )…

So really no point worrying about it ( your code is taking care of a scenario where

1. out of memory is thrown

2. Somehow things get back to normal ( how this will be done is hard to imagine  )

3.  And  you won’t  leak the memory…

).  But usually the best way is to terminate ( in that case anyway the leak does not matter much ).
Next what happens  when tomorrow some more code gets added ( around .. store the pointer line … )? Say someone calls a function f1(), which calls f2() and f2 throws some other exception???

In that case we have stored a deleted pointer into a collection… and this would be a hard bug to track…

This solution solves one case but raises a lot of other questions….

So  the way out is to use scoped allocations and get the advantages…

This is a very serious problem when you consider mutex locks instead of memory …. as forgetting to release a lock would get the system into a deadlock. So scoped guards are the solutions used there… Using similar strategy for memory management would be helpful
– cheers atul