Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-13 17:24:47

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.)