Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at