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. ( reads as "don't do it", as far as I can tell.)
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk