On 15/11/2013 09:26, Quoth Niall Douglas:
That description of its meaning came from me, so I'll answer this: it isn't defined by the standard to be that, but it IS defined by common idiomatic usage to be so. Any type registry in Boost I've seen appears to use name() (or raw_name() if _MSC_VER) as being the least cost way of obtaining a unique string identifier for some type specification.
Well, thus far when using type_info as an index into a collection I use only its type_info* value (as this is guaranteed by the standard to be unique per type but constant across multiple invocations of typeid on the same type of object), and name() is only used to print a human readable name (via MSVC) for diagnostic purposes (since the standard does NOT guarantee that the string value be unique, unlike the pointer, it's not really suitable for use as a key -- although granted most of the time you can get away with it). It's also faster. :) I don't know if this usage is more typical than yours or not, or how hard it is to emulate this with a non-compiler-supported library, but it's something that would have to be considered if the library is intended to be a drop-in replacement for existing code.
Certainly Antony has striven to duplicate that idiom by avoiding the use of malloc in name(), and hence on pre-C++11 compilers TypeIndex cannot return a string which is identical to what is returned by name() (or raw_name() if _MSC_VER) with std::type_info. I personally think there is a separate use case for both situations i.e. a standards compliant name() which isn't ABI compliant but is equally low cost, and a perfect RTTI-disabled substitute exactly replicating name() but with the cost of fire and forget mallocs - the only thing needing this is code which needs the mangling specifically, or code which needs RTTI disabled code to work perfectly with RTTI enabled code e.g. code which stores name() to persistent storage.
I think that at a minimum if RTTI is enabled then boost::type_info::name() must return exactly what std::type_info::name() would, on that platform. (This is still "least cost" since it'd just be passing the return value through without modification.) It should be free to add additional methods (such as raw_name or short_name or long_name or whatever) that can do whatever, including memory allocation and returning temporary values, but as long as drop-in-replacement is a goal it can't be allowed to change the behaviour of name() itself. When RTTI is disabled, of course, it has more freedom in the actual returned value because the standard name() doesn't exist. But it still must be able to return a const char* that has static lifetime, because people are expecting that from the RTTI-enabled case. (In particular, it must be legal to call name() on a temporary and use the returned value as a bare const char* at any later point in the code, even once the temporary is out of scope.) If the library is intended to be an alternative implementation that is *not* a drop-in replacement, then some of these strictures could be relaxed a bit (and it shouldn't inherit from std::type_info any more).