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: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-13 13:46:26

On Wednesday 13 November 2013 12:44:54 Niall Douglas wrote:
> 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.

AFAIR, std::type_info::name() gives no guarantees of the returned string 
contents whatsoever. I don't see why boost::type_info::name() should offer 
anything more. Also, I don't think it has to return the same string with and 
without RTTI enabled.

> 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().

I do not see why boost::type_info::raw_name() should have semantics equivalent 
to MSVC std::type_info::raw_name(), especially since the latter is non-
standard. We can implement boost::type_info::raw_name() in terms of MSVC 
std::type_info::raw_name(), but we surely cannot guarantee that it will always 
return what MSVC std::type_info::raw_name() does, on other compilers. This is 
the reason I objected against name_demangled() naming.

In my view, boost::type_info::raw_name() should be described as a function 
returning an implementation-defined string that may be equivalent to 
boost::type_info::name() but, if possible, may be in a platform-specific 
mangled format.

FWIW, boost::type_info interface description should allow to implement name(), 
raw_name() and pretty_name() all the same way - based on 
std::type_info::name() or another adequate source of strings in the lack of 
native RTTI.

> 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

A little irrelevant, but I personally don't think MSVC choice was wrong. I'd 
prefer std::type_info::name() to return a human readable string on most 
compilers instead of having to write hacks like __cxa_demangle().

> 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.

Again, std::type_info::name() does not have that meaning and there is no 
reason for boost::type_info::name() to have it. boost::type_info::name() 
should be exactly what it advertises itself - an equivalent for 
std::type_info::name(). For any other preference you should be using 
boost::type_info::raw_name() or boost::type_info::pretty_name().

> 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.