Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013

Subject: Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-25 14:35:34

On Monday 25 November 2013 13:42:24 Niall Douglas wrote:
> On 25 Nov 2013 at 10:23, Andrey Semashev wrote:
> > 
> > Sorry, I completely missed the part where type_index become a template. My
> > comments were made under impression that boost::type_index is not a
> > template and thus cannot have no members and be copyable.
> > 
> > So now it does not erase the type and cannot be used as a key in a
> > container. By all measure it is now a completely different beast than
> > std::type_index, so please, change the naming.
> 
> I think we've got to the point where only code explains meaning, so
> here is some fully working code for what I have in mind:
> 
> template<class T> class type_index : public static_string
> {
> public:
>   type_index() { symbol=static_string::int_storage<T>(); }
> };

Yes, I understood you meant something like that (although your type_index 
derives from static_string which does contain a data member). But that 
type_index cannot be used as a key in std::map for instance, and therefore it 
is not the equivalent for std::type_index which I'm interested in.

You could argue that you can use static_string in containers but what's the 
point of it if you can already use flyweight<string> or a string_ref with the 
same success. The point of type_index is not just strings but RTTI, which is 
in most cases more efficient than strings.

I'm sorry, but the design you suggest does not seem right to me. This is not 
what I would have wanted from a Boost.TypeIndex library.

> > And what about other platforms? Throwing an exception unconditionally
> > doesn't look like a portable solution.
> 
> If a compiler doesn't provide a magic macro for getting function
> signatures and its typeid() produces a compile error with RTTI off,
> all bets are off.

I'll remind you again that std::type_info::name() is not required to return a 
mangled name, and __func__ is not required either. On a perfectly compliant 
implementation your mangled_name() would fail and that is not acceptable, IMO.

You can provide such a function as an optional extension, with the necessary 
macros to detect its availability in the client code, but putting it into the 
core interface of the library is a mistake.

> > > At least four people objected to name() returning anything different
> > > to what std::type_info::name() does.
> > 
> > And that's what I suggested, isn't it?
> 
> I had understood that you want name() to return something compliant
> with the C++ standard, not what std::type_info::name() precisely
> returns.

I'm probably missing something. std::type_info::name() by definition returns 
something compliant with the standard, bugs aside. And I explicitly stated 
that boost::type_index::name() returns std::type_info::name().

> Without RTTI and C++11, you cannot return a static const
> char unique string type identifier which is identical to
> std::type_info::name() - see my code example above where I slice the
> front and end off the mangling, plus prepend the correct preamble. In
> short, for C++98 and 03, you need dynamic memory if you want
> identical output.

First, std::type_info::name() result is not required to be unique. Second, I 
never suggested boost::type_index::name() to return equivalent strings with 
and without RTTI. In fact, I welcomed the possibility of the opposite during 
the review.