Are member new/delete overloads in a derived class ever useful?

Question

I was just answering a question about the lack of placement delete corresponding to placement new. The reason seems to be the way operator delete is called according to the dynamic type of the object (corresponding to the type used to find operator new).

Placement new has been useful to me. When it comes to custom allocation, there is probably a reusable class where different instances manage different pools. Singletons are an anti-pattern and all that.

I can understand the convenience of making new thing; work without keeping track of an allocator, but doing things for different branches of the type hierarchy seems pretty convoluted.

Is there a real-world scenario where a derived class uses a different allocator from its base, and relies on a virtual destructor to find the correct member operator delete?

Lest this be subjective, I'll accept the answer which is most plausible. Let's not quibble over code smells or the "best" way of doing things.

Answer 1

I've actually used this in the past! It's useful for non-uniform memory architectures -- platforms with very small very fast memory areas without an OS, etc.

Specifically, envision e.g. an ARM chip with a small amount of TCM (tightly coupled memory; essentially, SRAM embedded on the SoC, with e.g. 1-cycle access time).

We then use profiler results very late in product development -- just before shipping (imagine that this is a cartridge for a popular handheld game system, for example) -- to determine that certain classes would benefit from being in this faster SRAM.

A simple member operator new that takes advantage of this TCM for just derived classes now may make sense: we can't afford to have the entire class hierarchy using this SRAM, but for certain low-instantiation-count but heavily-used derived classes, it becomes a simple and effective optimization. We've gotten back 2%-10% or more of frame time in a few cases by redirecting certain allocations this way.