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: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-25 02:12:59

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/template_info.hpp
[2] http://apolukhin.github.io/type_index/boost_typeindex/code_bloat.html