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/