Boost logo

Boost :

Subject: Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-25 00:44:30

On 25 Nov 2013 at 7:01, Andrey Semashev wrote:

> > about it. I would even, personally speaking, go so far as to only provide a
> > boost::type_index and no corresponding boost::type_info, especially if the
> > boost::type_id<T>() function can return a const boost::type_index<T>& and
> > therefore can be used as a static const lref, or copy constructed from it
> > etc.
> That's an unexpected turn.

My report tries to recommend what I personally think is the quickest
path to consensus. I should mention that Antony does not agree with
my proposals, and as he has the most experience through being the
library author I am happy to accept his judgment over mine (or anyone
else's for that matter).

> If boost::type_id<T>() returns a reference to a
> non-copyable object then it is useless for me because the essential advantage
> of type_index is its value semantics. And in such a design boost::type_index
> has very different semantics from std::type_index, so it shouldn't be named as
> such to avoid confusion. I would vote against accepting such design.

I'm not sure how you got this from my words. No one ever claimed that
my proposed boost::type_id<T>() would return an uncopyable object -
it returns a const boost::type_index<T>& to a statically constructed
instance. One can use the static instance lref directly, take its
address, or make a copy like std::type_index can. Under my design, a
boost::type_index<T> has sizeof=0 and merely contains a statically
constructed const char * shared by all instances. As it is zero
sized, it is therefore POD.

> > Bear in mind that user code can always subclass boost::type_index and add
> > their own name() implementation based on one or more of the above new
> > member functions.
> I don't think that mangled_name() (the last function that returns the cached
> mangled name) is a good idea. Requiring reimplementation of some particular
> mangling schemes (and by the way, why these specific ones?) is an unnecessary
> burden on the author (and maintainer later).

There is no need to reimplement any mangling schemes. For the MSVC
and Itanium mangling schemes you simply chop the front and end off
what is returned by __FUNCSIG__ or __FUNCTION__ and voila, there is
your correct mangling.

> Caching the name internally as a
> static member complicates the design (the cache has to be thread-safe and be
> accessible in global constructors/destructors). Caching the name as a regular
> member is unacceptable bloat (people expect type_index to be as light as a
> pointer to type_info; no dynamic memory allocation and associated possible
> exceptions are allowed).

unique_name() uses no dynamic memory and won't throw. That's your
only guarantee. If you want more functionality, you agree to pay its

Under what I proposed type_info permanently goes away. You get what
TypeIndex provides and it's up to you if you want to interoperate
with std::type_info. I proposed this because several reviewers felt
that type_info implies some relation to std::type_info. I personally
think that's daft, but that's not my role here - I am here to help
reach consensus, so I tried to disappear anything called type_info.

> I stand by the three functions we discussed during the review:
> // Returns std::type_info::name()
> const char* name() const noexcept;
> // Returns some low-level (possibly mangled) name
> const char* raw_name() const noexcept;
> // Returns some possibly human readable name
> std::string pretty_name() const;
> I'll add that I still think that the first one is required (at least, for
> compatibility with std::type_index) and has ho have exactly that semantics.

At least four people objected to name() returning anything different
to what std::type_info::name() does. At least two of those are to my
knowledge on the C++ standards committee (I could be wrong).

Once again I reiterate that if you really, really want name() to be
there, you are entirely free to subclass boost::type_index<T>
yourself and add your own name() returning whatever is safe for your


Currently unemployed and looking for work.
Work Portfolio:

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