Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2013-11-13 18:10:44

AMDG

On 11/13/2013 12:17 PM, Antony Polukhin wrote:
> 2013/11/13 Andrey Semashev <andrey.semashev_at_[hidden]>
> 
>> 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