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: 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 [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.