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. The no-RTTI case does use full somewhat-human-readable names under the covers though, so the more types it is used with the more code space will be consumed by static strings (especially since each one incurs a "boost::detail::" namespace prefix penalty, along with some less avoidable odds and ends). [2] But this doesn't impact runtime performance, just binary size. (ie. the main change from the currently proposed code would be just dropping boost::type_info, and letting boost::type_index point to a std::type_info by containment instead of through inheritance, and retaining the parallel template_index -- or possibly keeping ONLY template_index and dropping RTTI compatibility.) Or at least I think that's what we're discussing. Sometimes it's hard to keep track. :) 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. [1] https://github.com/apolukhin/type_index/blob/master/boost/type_index/templat... [2] http://apolukhin.github.io/type_index/boost_typeindex/code_bloat.html