On Monday 25 November 2013 20:12:59 Gavin Lambert wrote:
On 25/11/2013 18:02, Quoth Andrey Semashev:
If so, that implies that copying type_index would be inefficient. I don't think this is a reasonable tradeoff. After all, type names is just one feature. In the motivating use case (a key in an associative container) type names are not needed and the proposed design would result in considerable overhead.
Either way it'd just be a single pointer. Either a pointer to the std::type_info if RTTI is enabled or a const char * if RTTI is disabled (see template_info [1], probably just renamed to template_index). This is the same as std::type_index.
I suppose it all depends on the implementation details. Niall has already stated that his idea was to make type_index an empty template class, which makes the copying overhead non-existent. I have to say though that this would not be the library I'm interested in. If type_index is not a template though, one possible implementation is to store a single pointer to the global descriptor that has a reference to std::type_info and the string mangled_name() returns. This way copying costs are minimized but other operations involving std::type_info become slightly more expensive due to an additional level of indirection. That leaves the descriptor lifetime and thread safety the only significant problem. Another way to implement it is to make the string returned by mangled_name() a member of type_index (in addition to the pointer to std::type_info), in which case all the problems with overhead and exceptions are in place. What I'm trying to say is that neither of these solutions appeal to me. What I want is a simple wrapper around std::type_info with value semantics and probably some type name helpers as long as they don't bring additional problems to the design, like the ones I mentioned. mangled_name() is a double evil in my view, because in addition to the problems it causes it also requires us to implement mangling schemes (I see no point in this function if it simply throws on some platforms). Even the no-RTTI case I consider as secondary, although it is perfectly supported by the design where (non- template) type_index refers to a type name string or a global object that contains it.
Regarding type names, in the proposed design (both before and next) they were essential as it does comparisons on the name string as well as the pointer value. This is a potential pessimisation from std::type_index that I'm still a little dubious about (though it should have minimal impact when searching a hashed container), but as Niall pointed out it does enable scenarios where type information has to be used across DLL/SO boundaries, as in plugins.
Type names are only essential to work around bugs on some platforms (i.e. inability to compare type_infos across module boundaries) or when native RTTI is disabled. In the normal world type names are completely optional.