On 26/11/2013 14:41, Quoth Niall Douglas:
Both GCC and MSVC internally use strcmp() on those strings when comparing type_info's, including for ordering for use in std::map<>. hash_code() I would also be fairly sure is simply a hash of the mangled type string. Therefore what I proposed is almost the same thing as RTTI, and certainly IS the same thing for use as value types inside containers. The only difference when RTTI is off is that the strings become a bit longer to compare and store, and that's it.
The distinction is that std::type_index is intended specifically to be "the thing you use as map keys", whereas your suggested one cannot be used that way, and instead you must extract the string out of it and use that as the key instead. Technically these may not be significantly different approaches but at least for code readability purposes it's nicer to have a non-templated type_index that can be used as the key directly. Hence the indirection of using a templated free function to return a non-templated instance. It's also nicer to have the type_index as the key type when both purposes are required: you want it to use a "fast" (presumably mangled) representation when acting in the role of a key, but you also want to be able to easily obtain a "readable" (non-mangled) name for display purposes at some later time. (These two representations don't *have* to be different, eg. when RTTI is disabled and only the longer name is known; but when both forms are known to the implementation it is useful to use the appropriate one in each role.) I think Antony's proposed version is very close to this ideal; we just need to strip off or tweak some of the dodgier bits.
Unless I misunderstood something, the previous complaints about name() was that it MUST return EXACTLY what std::type_info::name()/raw_name() does. If it can't return EXACTLY what name()/raw_name() does, it must not be there at all.
Where RTTI is enabled throughout, the two must return compatible values (and ideally be directly comparable). Where RTTI is disabled throughout, the std one doesn't exist (or at least only works on a subset of types, in the case of MSVC) so boost::type_id can return whatever it likes. Where some compilation units are built with RTTI enabled and some are built with RTTI disabled, I'm less sure what the best behaviour is, but I was under the impression that the library wasn't intending to support this case anyway. ([1] reads as "don't do it", as far as I can tell.) [1] http://apolukhin.github.io/type_index/boost_typeindex/mixing_sources_with_rt... It could be a reasonable alternative to take *only* boost::template_info (as "template_index") and have that be the entirety of the library, forgoing any attempt to be compatible with std::type_info. However I think this is not the best choice, as taking advantage of RTTI when available (and it is usually available) produces superior results.