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: 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 
unique_name().

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.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/