RTTI, runtime type information, is the metadata the compiler attaches to polymorphic classes to support dynamic_cast (checked downcasting within a class hierarchy) and typeid (querying an object's actual type at runtime). It's disabled on embedded (-fno-rtti) because that metadata costs flash on every polymorphic type, and dynamic_cast does a runtime walk of the type graph that isn't constant time. More fundamentally, needing dynamic_cast usually signals a design that branches on "what type is this?" when it should instead expose the needed behavior as a virtual method and call it polymorphically, sensor->read() rather than testing the concrete type and acting accordingly. So you both remove the cost and get a cleaner design. Even virtual functions (which don't require RTTI) are used selectively on MCUs because of the vtable pointer and indirect call, but they're far cheaper than RTTI-based type queries.
C++ for Embedded · Interview question
What is RTTI and why do embedded builds often disable it?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
What to Avoid on MCUs
The three C++ features that cost more than they're worth on a microcontroller (exceptions, RTTI, and dynamic allocation): why they hurt, and the deterministic patterns to use instead.