The precise definition is probably something along the line of the trivial type named requirement, or at least needs a ‘trivial’ constructor and destructor.
If you mean that monstrosity, anyone caught using that should have their programming licence revoked and then executed by firing squad.
Most uses of polymorphism require
which would violate ‘triviality’, which is potentially a requirement for ROM-ing.
I’m not sure why you’d want to put a runtime polymorphic object in ROM anyway though,
that seems like it would potentially defeat the point.
Unless the idea is to have objects of subclasses stored in ROM and reference them through parent class pointers or references.
But if that’s the case you don’t need a virtual destructor because you’d want those objects to be trivially destructible anyway.
(Being trivially destructible is almost certainly a guarantee for something to exist in ROM - you want destruction to be a ‘nop’ so it can be optimised out completely.)
The most important part to remember is ‘not user-provided’.
(I.e. implicitly defined, implicitly defaulted or explicitly defaulted.)
This is true, but it would certainly be an advanced article (the fact we’re mentioning triviality at all is a big hint to that), and I’m not sure anyone actually knows definitively.
Unless it’s documented by mbed it might take a bit of experimentation and digging.