Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-24 19:42:34

On 25 Nov 2013 at 12:23, Gavin Lambert wrote:

> Given that I'm still mostly using not-C++11 compilers I get a little 
> nervous when I see "class enum"s.  Not that this is a reason to not do 
> it. :)

Oh sure, the code I wrote was purely for illustration. It would get 
wrapped in the appropriate Boost class enum macro magic in practice.

> I'm not sure what the motivation for having the returned mangled type 
> configurable is though.  Presumably most existing use cases would just 
> want Native, and the burden of providing alternates might be significant 
> (and therefore left unimplemented and throwing an exception, as 
> specified, limiting the potential usefulness of this anyway).  Though as 
> I've said before I admit to ignorance about many of the use cases, so 
> maybe there is a need for this that I am unaware of.

You're right I should have explained this much better. There is a 
need for a truly portable type specification string such that code 
from GCC can work with code from MSVC and so on where the type string 
is being kept in storage. Antony wants to (much later on) add a 
custom type mangling scheme to TypeIndex which would be universal and 
absolutely as compact as possible (symbol mangling schemes are 
designed to be fast rather than compact). I simply had the class enum 
in there to facilitate such an extension later.

(Also, I think it very possible that clang might one day let you 
generate any mangling scheme you like, so I didn't want to rule that 
out).

> Why not just specify a mangled_name that will return the native mangled 
> name if it can, but is allowed to return the same as unique_name?  Or is 
> that too close to what unique_name itself will do?

mangled_name() here is *guaranteed* to return exactly what 
std::type_info does, even if RTTI is turned off. I would expect such 
a facility to be highly useful for where boost::type_index binaries 
might be mixed with std::type_info binaries and you need to compare a 
type_index indexed type with a std::type_info indexed type. Also, of 
course, sometimes you really do want the exact symbol mangling to be 
returned because you're going to parse that mangling into a AST, and 
use that AST to auto-generate yourself some LLVM :).

Niall

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