Boost logo

Boost :

Subject: Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-27 02:07:49

On 26 Nov 2013 at 16:09, Gavin Lambert wrote:

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

Well, I did have in mind that the underlying string carrying type
would provide the appropriate map and hash semantics based on

Andrey made a good point though - it's basically a string_ref. There
is a part of me which thinks that subclassing string_ref with
unique_name()/mangled_name()/pretty_name() etc might actually not be
a terrible idea (and then subclassing that with type_index<T>).

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

Sure. We've ended up straying quite far now from anything Antony will
or is considering to produce. We're really musing about our personal
philosophical differences in C++ design now.

> 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.)

No it wasn't and isn't. That idea was all mine. I have bad memories
of fighting precompiled binary blobs with stupid options you see, and
I can see a very valid use case being mixing up RTTI on and RTTI off
code. A method for interop here would be really useful, especially as
it's so cheap to implement. I agree it lacks a "business case" right
now though.

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

Sure. I had in mind my unique_name() static initialiser would simply
yank name() from std::type_info where that was available mainly
because it's less code bloaty (MSVC always, GCC with RTTI on).

Ok, I leave for the US for Thanksgiving in a few hours, so I probably
am off list for a good while. Happy Thanksgiving every one.


Currently unemployed and looking for work.
Work Portfolio:

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