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/