> operator delete is required whenever we give a base class a virtual destructor—as is standard practice—even if we never heap-allocate an object of that class.
I'm not sure why you would need a virtual destructor if you don't heap allocate a class and are not going to call delete, as it will not be polymorfically deleted anyway, so you can do with a non-virtual destructor.
The main motivation is just that experienced C++ devs (myself included) have the rule, "base classes should have virtual destructors" drummed into their heads. Defining operator delete (even if the compiler elides it since, like you pointed out, it's never needed) allows devs to continue that habit without any negative consequences.
This makes instances of all derived classes be at least as long as a pointer -- many of them will be adding a data member so be longer yet, which will disqualify them for passing over in a general-purpose register (details per each ABI). This can have dramatic adverse effect on the overall performance of the code which, depending on the domain, can be very negative.
EDIT: actually, adding a virtual, or a destructor, alone (without size considerations) makes the type non-POD which prevents it from being returned in a register.
To be honest, a derived class already cannot be a POD. But stuffing the vtable pointer into any derived class is indeed wasteful for embedded programming and opens another way to exploit your system (if you care about security) by leaving code pointers at the fixed addresses in r/w memory.
Great points. In our cases, these objects were few in number and were accessed infrequently through a pointer, so I don't think there's much to be concerned about. Avoiding unnecessary vtables is definitely something to keep in mind, though.
also an operator delete is very much not required if you give a base class a virtual destructor, only if you are using a custom allocator; probably the OP is missing something in his description.
This is not about defining a custom operator delete, it's about defining it at all, because when compiling with -ffreestanding it is not provided, and apparently virtual destructors synthesize call to the delete operator.
that's kind of circular... having a virtual destructor is useful only if you actually are going to call delete. If you want to make sure that the object is never heap allocated, just declare the operator new as deleted and at least the issue would be always caught at compile time instead of just having a chance of catching it a runtime.
I'm not sure why you would need a virtual destructor if you don't heap allocate a class and are not going to call delete, as it will not be polymorfically deleted anyway, so you can do with a non-virtual destructor.