https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
Bug ID: 117683 Summary: provide a way to remove all C++ class names from the binary Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: rdiez-2006 at rd10 dot de Target Milestone: --- I am writing embedded software for very resource-constrained microcontrollers, and I have noticed that the C++ class names end up in the binary, even if never used. These class names have to do with the typeid operator and the std::type_info class. Example code: class very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx { public: virtual void some_method ( void ) { } }; static const very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx static_instance; int main ( void ) { return 5; } Run this command to verify it: $ g++ typeinfo.cpp && strip a.out && strings a.out | grep very 55very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx Tool 'objdump' prints this line for a.out: 0000000000002020 w O .rodata 000000000000003a typeinfo name for very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx This probably has to do with vtables, and is similar to bug 117672 ("Remove unused virtual methods"). Once that bug is fixed, these class names may be optimised away if unused. There is a difference however: I would like to forcibly remove all those class names from the binaries, in order to save program space (flash memory). Class names can be rather long if nested classes and templates are involved. Besides, I don't like having to shorten the names just to save memory. I have read the following on the Internet: -----8<-----8<-----8<----- std::type_info::name const char* name() const; Returns an implementation defined null-terminated character string containing the name of the type. No guarantees are given; in particular, the returned string can be identical for several types and change between invocations of the same program. -----8<-----8<-----8<----- Because there are no guarantees (allegedly), I am guessing it should be OK to always return an empty string.