AMDG On 11/13/2013 12:17 PM, Antony Polukhin wrote:
2013/11/13 Andrey Semashev
On Wednesday 13 November 2013 12:44:54 Niall Douglas wrote:
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?
I don't see the point in such duplication. boost::type_index will only work with boost::type_info anyway.
boost::type_index and std::type_info can be compared with each other. boost::type_info is derived from std::type_info and it can be used in any method that accepts std::type_info.
<snip>
Let's change the balance in a following way (NEW WAY): * const char* name() // same as std::type_info::raw_name() * const char* raw_name() // // same as std::type_info::raw_name() * std::string pretty_name() // was name_demangled()
As far as I am concerned, boost::type_info::name *must* return the same value as std::type_info::name. You have to expect that use of boost::type_info will be mixed with std::type_info. It's unreasonable to expect everything to use boost::type_info, and if the behavior is different, it *will* cause surprises. You could perhaps make a case for different behavior if boost::type_info were completely separate, but since boost::type_info inherits from std::type_info, there's absolutely no excuse. In Christ, Steven Watanabe