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-14 15:26:23

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/