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 22:09:35

On 26/11/2013 14:41, Quoth Niall Douglas:
> Both GCC and MSVC internally use strcmp() on those strings when
> comparing type_info's, including for ordering for use in std::map<>.
> hash_code() I would also be fairly sure is simply a hash of the
> mangled type string. Therefore what I proposed is almost the same
> thing as RTTI, and certainly IS the same thing for use as value types
> inside containers. The only difference when RTTI is off is that the
> strings become a bit longer to compare and store, and that's it.

The distinction is that std::type_index is intended specifically to be 
"the thing you use as map keys", whereas your suggested one cannot be 
used that way, and instead you must extract the string out of it and use 
that as the key instead.

Technically these may not be significantly different approaches but at 
least for code readability purposes it's nicer to have a non-templated 
type_index that can be used as the key directly.  Hence the indirection 
of using a templated free function to return a non-templated instance.

It's also nicer to have the type_index as the key type when both 
purposes are required: you want it to use a "fast" (presumably mangled) 
representation when acting in the role of a key, but you also want to be 
able to easily obtain a "readable" (non-mangled) name for display 
purposes at some later time.  (These two representations don't *have* to 
be different, eg. when RTTI is disabled and only the longer name is 
known; but when both forms are known to the implementation it is useful 
to use the appropriate one in each role.)

I think Antony's proposed version is very close to this ideal; we just 
need to strip off or tweak some of the dodgier bits.

> Unless I misunderstood something, the previous complaints about
> name() was that it MUST return EXACTLY what
> std::type_info::name()/raw_name() does. If it can't return EXACTLY
> what name()/raw_name() does, it must not be there at all.

Where RTTI is enabled throughout, the two must return compatible values 
(and ideally be directly comparable).  Where RTTI is disabled 
throughout, the std one doesn't exist (or at least only works on a 
subset of types, in the case of MSVC) so boost::type_id can return 
whatever it likes.

Where some compilation units are built with RTTI enabled and some are 
built with RTTI disabled, I'm less sure what the best behaviour is, but 
I was under the impression that the library wasn't intending to support 
this case anyway.  ([1] reads as "don't do it", as far as I can tell.)

[1] 
http://apolukhin.github.io/type_index/boost_typeindex/mixing_sources_with_rtti_on_and_.html

It could be a reasonable alternative to take *only* boost::template_info 
(as "template_index") and have that be the entirety of the library, 
forgoing any attempt to be compatible with std::type_info.  However I 
think this is not the best choice, as taking advantage of RTTI when 
available (and it is usually available) produces superior results.