Re: [boost] Peer Review Report for proposed Boost.TypeIndex v2.1 Nov 12th – 21st 2013

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

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

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/