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.