Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at