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.

Answer 2

I've actually never used new/delete overloads in a derived class or have I ever thought about it, but this question was interesting and I decided to perform some research and give it a shot. I found a couple suitable references:

ARM http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka14267.html

This reference actually has sample code of a derived class overloading its base class overloaded new.

Vanderbilt University http://www.vuse.vanderbilt.edu/~adamsja/Courses/CS251/Projects/4/memPool.pdf

This reference doesn't provide any material explicitly regarding overloading new in a derived class, however, it mentions some interesting reasons as why to overload new. Those reasons include:

• To compensate for suboptimal alignment in the default allocator
• To cluster related objects near one another
• To obtain unconventional behavior such as overwriting memory with zeros to increase the security of the application data

Now based upon those two references, I've decided that there could be a few reasons for overloading new/delete in a derived class. My reasons basically align with the reasons I listed from the VU presentation, but also seem relevant based upon the ARM reference implying to me an embedded or specialized scenario.

• Embedded systems are often very custom at the hardware level, however, are common in a standardized sense at the software level. I could see a situation where depending on a configuration setting/hardware strap, that at run-time a certain type of object (derived class) is chosen because it needs to allocate memory in a specific manner or specific location.
• Clustering seems plausible because I could envision a scenario where some objects are treated the same in a high-level "workflow" but when processed, the different types of those objects are handled very differently. It might be beneficial to locate specific types of objects near each other for process intensive tasks (ie. searching, sorting, prioritizing, etc).
• The last point is interesting because I could see certain cases where the allocation depends on the security classification of the information being stored.

Again, I haven't ever found a reason or actually implemented something like you have mentioned, but these are my thoughts with a little investigation.

Answer 3

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?

I am not sure what you would consider a real-world scenario, but the obvious example that comes to my mind is an inheritance hierarchy that's rooted in an abstract base class, with vastly different (in size) derived classes, a lot of which are created and destroyed regularly, while speed is required for those allocations/deallocations.

You might want custom allocators for those derived classes, because allocators for memory blobs of a specific size can be lightning fast, and you might want to use different allocators for each derived class, because their sizes are so different.

I can't give you a concrete example for this, though, because over the years I have found that avoiding allocation/deallocation pays off way better than speeding it up, so in almost twenty years I have rarely ever overloaded class-specific new/delete. (Of course, as usually when we're talking about sophisticated optimization, "gaming" comes up, so we could imagine a game that needs to create and destroy vast amounts of very different entities.)

Answer 4

A member operator new/delete may be useful to remove undesirable custom allocation from a base class, for example if the base wasn't intended to be extended. But the base would either need a virtual destructor, or the base object must never be the subject of delete.

Actually, the virtual destructor dispatch of operator delete is required independently of overloading. The feature probably exists to support multiple inheritance, and dynamically finding the correct member operator delete is just a side effect.

The rule is simply that a virtual destructor for a most-derived object calls operator delete. The main reason is to pass the correct most-derived pointer and size. That the context also enables the program to dynamically find the correct deallocation function is just a happy side effect.

So there may or may not be a useful application for dynamic delete dispatch, but there absolutely isn't a dedicated mechanism to make it work.

Simple demo:

struct pad {
    int x;

    virtual ~pad() {}
};

struct b {
    int x;
};

struct vb {
    int x;

    virtual ~vb() {}
};

struct d : pad, b, vb {};

void operator delete( void *p ) {
    std::cout << "free " << p << '\n';
}

int main() {
    std::cout << "With virtual destructor:\n";
    d *p = new d;
    std::cout << "allocate " << p << ", delete " << static_cast< vb * >( p ) << '\n';
    delete static_cast< vb * >( p );

    std::cout << "With plain destructor:\n";
    p = new d;
    std::cout << "allocate " << p << ", delete " << static_cast< b * >( p ) << '\n';
    delete static_cast< b * >( p );
}