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/