On 13/11/2013 23:16, Quoth Antony Polukhin:
* const char* name() // same as std::type_info::name() * const char* raw_name() // mangled/short/not very readable name * std::string pretty_name() // was name_demangled()
That'd be ok, but the reason why I suggested "short" and "long" rather than "raw" and "pretty" is that even "raw" and "pretty" make implications that we might not follow (eg. with RTTI off, all three will return the same value, which might be neither raw nor pretty, but is at least relatively both short and long if it's the only possible name). (And a future extension might be an "even prettier name" that tries to remove leading "struct" etc.) Also, earlier in the thread you dismissed the idea of storing a string buffer within the type_info, but I'm wondering if that might not be a good idea after all. If type_info is permitted to contain std::string members that are initially empty but populated on first call to their corresponding name function, then repeated calls to the same name function would only pay any demangling/parsing cost on the first call. It won't make any difference in the direct typeid rvalue->name case, but if code is keeping a type_info instance around (eg. as a key in a container) it seems reasonable to assume that one of the name methods might get called more than once. Slight downside is the extra size of the type_info (particularly in the case where it is used without ever asking for the name), but I don't think this is too onerous. It's tempting to also make all the methods return "const char *" (to possibly save on copies) if we have member strings to return them from, but this is still potentially dangerous if the user assumes the string has static lifetime when called on a temporary type_info (which is probably a common pattern for the drop-in-replacement case). On the other hand, the drop-in-replacement probably wouldn't be calling pretty_name/long_name so it might not matter; we'd just need to document that the return value should immediately be saved to a std::string if called on a temporary type_info, or that the type_info should be kept around longer. (This would be adding a copy in the temporary case to save copies in the repeated-call case though. I'm not sure which direction would be better to optimise towards.)