On Wednesday 13 November 2013 14:29:07 Niall Douglas wrote:
On 13 Nov 2013 at 22:46, Andrey Semashev 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.
There are two primary use cases for boost::type_info: (i) as a better (static) std::type_info (ii) as a direct std::type_info substitute working with RTTI off.
What boost::type_info does not currently provide which std::type_info does is a method of retrieving the type mangling string with RTTI off. It could be easily added if name() can return a std::string, but that is outside the scope of this peer review.
Those use cases are not identical.
Yes, but they also are not exclusive. At least, not with respect to name functions.
I also don't see why my proposal to provide both type_info replacements has anything to do with your arguments which appear to mostly be based on API purity rather than practical concerns. I proposed that boost::type_info be pure and fitting your stated wishes, while a new boost::type_info_std (which is implicitly convertible to a boost::type_info) is quirky. You get what you want, while people wanting a direct drop in perfect substitute for std::type_info also get what they want. Trying to get boost::type_info to on its own be everything to everybody I don't think is wise because the use cases are semantically distinct.
I don't like the idea of having two practically equivalent classes which basically do the same thing. The difference between the classes would be in the behavior, which is not specified by the standard in the first place and can be adjusted in a non-breaking manner in a unified boost::type_info class.