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: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-13 12:44:54

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.

My concern is that MSVC's raw_name() does something very explicit: if 
you read 
http://msdn.microsoft.com/en-us/library/vstudio/70ky2y6k.aspx, it 
explicitly says that raw_name() specifically returns the mangled 
("decorated") form of the type expression. TypeIndex, with RTTI off, 
would not return such a string for its raw_name().

Note I have no complaint if raw_name() exists with RTTI on (and 
returns the mangled string), but vanishes if RTTI is off and 
therefore correctly breaks compilation.

Regarding the problem of name() compatibility: it is deeply 
unfortunate that MSVC chose that name() should be demangled, while 
everyone else chose that name() should be mangled. It means you see 
this everywhere which uses type_info:

#ifdef _MSC_VER
ti.raw_name()
#else
ti.name()
#endif

One of the things I really like about boost::type_info is that we do 
away with this silliness and name() always means "the shortest unique 
representation string" on every platform.

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.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/