Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What is the actual purpose of std::type_info::name()?

Tags:

Today a colleague of mine came and asked me the question as mentioned in the title.
He's currently trying to reduce the binaries footprint of a codebase, that is also used on small targets (like Cortex M3 and alike). Apparently they have decided to compile with RTTI switched on (GCC actually), to support proper exception handling.

Well, his major complaint was why std::type_info::name() is actually needed at all for support of RTTI, and asked, if I know a way to just suppress generation of the string literals needed to support this, or at least to shorten them.

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.

A ,- however compiler specific -, implementation of e.g. the dynamic_cast<> operator would not use this information, but rather something like a hash-tag for type determination (similar for catch() blocks with exception handling).
I think the latter is clearly expressed by the current standard definitions for

  1. std::type_info::hash_code
  2. std::type_index

I had to agree, that I also don't really see a point of using std::type_info::name(), other than for debugging (logging) purposes. I wasn't a 100% sure that exception handling will work just without RTTI with current versions of GCC (I think they're using 4.9.1), so I hesitated to recommend simply switching off RTTI.
Also it's the case that dynamic_casts<> are used in their code base, but for these, I just recommended not to use it, in favor of static_cast (they don't really have something like plugins, or need for runtime type detection other than assertions).


Question:

  • Are there real life, production code level use cases for std::type_info::name() other than logging?

Sub-Questions (more concrete):

  • Does anyone have an idea, how to overcome (work around) the generation of these useless string literals (under assumption they'll never be used)?

  • Is RTTI really (still) needed to support exception handling with GCC?
    (This part is well solved now by @Sehe's answer, and I have accepted it. The other sub-question still remains for the left over generated std::type_info instances for any exceptions used in the code. We're pretty sure, that these literals are never used anywhere)


Bit of related: Strip unused runtime functions which bloat executable (GCC)

like image 936
πάντα ῥεῖ Avatar asked Mar 04 '15 18:03

πάντα ῥεῖ


People also ask

What is std :: type_info?

std::type_info The class type_info holds implementation-specific information about a type, including the name of the type and means to compare two types for equality or collating order. This is the class returned by the typeid operator.

What does Typeid return C++?

The typeid operator returns an lvalue of type const std::type_info that represents the type of expression expr. You must include the standard template library header <typeinfo> to use the typeid operator.

What is typeof in C++?

The typeof operator returns the type of its argument, which can be an expression or a type. The language feature provides a way to derive the type from an expression. Given an expression e , __typeof__(e) can be used anywhere a type name is needed, for example in a declaration or in a cast.


1 Answers

Isolating this bit:

  • The point is, if they switch off RTTI, will exception handling still work properly in GCC? — πάντα ῥεῖ 1 hour ago

The answer is yes:

-fno-rtti

Disable generation of information about every class with virtual functions for use by the C++ runtime type identification features (dynamic_cast and typeid). If you don't use those parts of the language, you can save some space by using this flag. Note that exception handling uses the same information, but it will generate it as needed. The dynamic_cast operator can still be used for casts that do not require runtime type information, i.e. casts to void * or to unambiguous base classes.

like image 97
sehe Avatar answered Sep 29 '22 01:09

sehe