Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-13 14:29:07
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. 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.
-- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk