Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at