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: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-14 16:51:08

On 15/11/2013 09:26, Quoth Niall Douglas:
> 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.

Well, thus far when using type_info as an index into a collection I use 
only its type_info* value (as this is guaranteed by the standard to be 
unique per type but constant across multiple invocations of typeid on 
the same type of object), and name() is only used to print a human 
readable name (via MSVC) for diagnostic purposes (since the standard 
does NOT guarantee that the string value be unique, unlike the pointer, 
it's not really suitable for use as a key -- although granted most of 
the time you can get away with it).  It's also faster. :)

I don't know if this usage is more typical than yours or not, or how 
hard it is to emulate this with a non-compiler-supported library, but 
it's something that would have to be considered if the library is 
intended to be a drop-in replacement for existing code.

> 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.

I think that at a minimum if RTTI is enabled then 
boost::type_info::name() must return exactly what std::type_info::name() 
would, on that platform.  (This is still "least cost" since it'd just be 
passing the return value through without modification.)

It should be free to add additional methods (such as raw_name or 
short_name or long_name or whatever) that can do whatever, including 
memory allocation and returning temporary values, but as long as 
drop-in-replacement is a goal it can't be allowed to change the 
behaviour of name() itself.

When RTTI is disabled, of course, it has more freedom in the actual 
returned value because the standard name() doesn't exist.  But it still 
must be able to return a const char* that has static lifetime, because 
people are expecting that from the RTTI-enabled case.  (In particular, 
it must be legal to call name() on a temporary and use the returned 
value as a bare const char* at any later point in the code, even once 
the temporary is out of scope.)

If the library is intended to be an alternative implementation that is 
*not* a drop-in replacement, then some of these strictures could be 
relaxed a bit (and it shouldn't inherit from std::type_info any more).