Boost logo

Boost :

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.


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