On 14 Nov 2013 at 10:49, Gavin Lambert wrote:
* we loose the meaning of name() as a "fast short nonreadable name" and get something indeterminated instead
Where is that meaning assigned? I don't believe the standard specifies what form the return value will take, just that it's some unique string literal.
That description of its meaning came from me, so I'll answer this: it isn't defined by the standard to be that, but it IS defined by common idiomatic usage to be so. Any type registry in Boost I've seen appears to use name() (or raw_name() if _MSC_VER) as being the least cost way of obtaining a unique string identifier for some type specification. Certainly Antony has striven to duplicate that idiom by avoiding the use of malloc in name(), and hence on pre-C++11 compilers TypeIndex cannot return a string which is identical to what is returned by name() (or raw_name() if _MSC_VER) with std::type_info. I personally think there is a separate use case for both situations i.e. a standards compliant name() which isn't ABI compliant but is equally low cost, and a perfect RTTI-disabled substitute exactly replicating name() but with the cost of fire and forget mallocs - the only thing needing this is code which needs the mangling specifically, or code which needs RTTI disabled code to work perfectly with RTTI enabled code e.g. code which stores name() to persistent storage. For me personally that would imply extra adapters adding such extra functionality if and only if there is sufficient demand for it, but we'll see how things look at the end of peer review. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/