On 13 Nov 2013 at 14:28, Antony Polukhin wrote:
* 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()
Looks great to me.
I like it too. Now it is a drop in replacement that supports even the MSVC extensions.
I'm afraid I disagree - you're breaking the interface contract with std::type_info when RTTI is off. Previous commenters may not realise that template_info::name() does NOT return the same value as type_info::name() when RTTI is off. It returns an internal unique const char * value, that's all. My concern is that MSVC's raw_name() does something very explicit: if you read http://msdn.microsoft.com/en-us/library/vstudio/70ky2y6k.aspx, it explicitly says that raw_name() specifically returns the mangled ("decorated") form of the type expression. TypeIndex, with RTTI off, would not return such a string for its raw_name(). Note I have no complaint if raw_name() exists with RTTI on (and returns the mangled string), but vanishes if RTTI is off and therefore correctly breaks compilation. Regarding the problem of name() compatibility: it is deeply unfortunate that MSVC chose that name() should be demangled, while everyone else chose that name() should be mangled. It means you see this everywhere which uses type_info: #ifdef _MSC_VER ti.raw_name() #else ti.name() #endif One of the things I really like about boost::type_info is that we do away with this silliness and name() always means "the shortest unique representation string" on every platform. Can I suggest this instead: instead of making boost::type_info more like the flawed std::type_info, can you leave boost::type_info to be pure and instead add a new boost::type_info_std or something which does replicate std::type_info's implementation specific quirks? That way we get boost::type_info being as std::type_info ought to have been, while those who really need std::type_info to be quirky get boost::type_info_std as a direct replacement? I personally suspect that the pure unquirky boost::type_info will in fact be a more popular std::type_info replacement once authors think it through. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/