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. Let me put the question in other way: do we want to support MS extensions? If yes, then advantages are: * less user code will be broken during conversion for std:;type_info to boost::type_info (see for example boost::any::type()) Disadvantages: * supporting vendor specific extensions is a bad practice * we loose the meaning of name() as a "fast short nonreadable name" and get something indeterminated instead * more functions => more fuss for the user * calls to name() will become slower on MS Windows 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() Now we have following advantages: * less user code will be broken during conversion for std::type_info to boost::type_info (see for example boost::any::type()) * we do not loose the meaning of name() as a "fast short nonreadable name" and do not get indeterminated faunctions instead * calls to name() are fast Disadvantages: * supporting vendor specific extensions is a bad practice * more functions => more fuss for the user * calls to name() on MSVC will return different result (however name() may return whatever it whants, according to Standard) But do we *really* want to encourage users that write unportable code? -- Best regards, Antony Polukhin