Subject: Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th â 21st 2013
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-11-25 02:59:16
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 , 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk