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: Antony Polukhin (antoshkka_at_[hidden])
Date: 2013-11-13 14:33:34

2013/11/13 Niall Douglas <s_sourceforge_at_[hidden]>

> On 13 Nov 2013 at 14:28, Antony Polukhin wrote:
>
> > > > * const char* name() // same as std::type_info::name()
> > > > * const char* raw_name() // mangled/short/not very readable name
> > > > * std::string pretty_name() // was name_demangled()
> > >
> > > Looks great to me.
> > >
> >
> > I like it too. Now it is a drop in replacement that supports even the
> MSVC
> > extensions.
>
> I'm afraid I disagree - you're breaking the interface contract with
> std::type_info when RTTI is off.
>
> Previous commenters may not realise that template_info::name() does
> NOT return the same value as type_info::name() when RTTI is off. It
> returns an internal unique const char * value, that's all.
>

Well, actually current implementation does return the same value. MSVC
allows to use typeinfo for Types even with RTTI disabled, so it is possible
to do so.

> 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?
>
> That way we get boost::type_info being as std::type_info ought to
> have been, while those who really need std::type_info to be quirky
> get boost::type_info_std as a direct replacement? I personally
> suspect that the pure unquirky boost::type_info will in fact be a
> more popular std::type_info replacement once authors think it
> through.
>

I do not think that multiplying entities is good. It's better to have a
single class that suits (almost) all the situations.

-- 
Best regards,
Antony Polukhin