On Sun, Apr 20, 2014 at 8:14 PM, Niall Douglas
1. What is your evaluation of the design?
It looks good because it seems to fill all of my needs. If it actually fill it's promise considering the issues with what the standard provide, it's very good. I was wondering though: - what is the behaviours of pretty_name() when the type is in namespaces (there are no example of this); - what is the behaviours of pretty_name() when the type is in an anonymous namespace? In particular when there are two types with the same name in different compilation units but in anonymous namespaces?
2. What is your evaluation of the implementation?
I didn't read the implementation.
3. What is your evaluation of the documentation?
The comparison tables helps to get quickly an understanding of how to use it so it's good. I wonder though if someone not used to typeid(), std::type_index and std::type_info would understand it quickly, but I guess the target audience is people already using them anyway. I would like to see examples of output of name functions in the namespace, sub-namespace and anonymous namespace cases. Also, the point on shared-library boundaries is not clear to me: how does this library fix that issue exactly? A quick explaination somewhere would be good. The "Example with Boost.Variant" would benefit from a short explaination of why there are these macros in the original boost.variant implementation. Unfortunately the full interface of type_info it is a bit hard to find because there are missing links to the actualy types on this page: http://apolukhin.github.io/type_index/boost/typeind/type_info.html Strangely enough the type_index page does have the right links: http://apolukhin.github.io/type_index/boost/typeind/type_index.html I think this should be fixed. Also, on these pages: http://apolukhin.github.io/type_index/boost/typeind/stl_type_index.html http://apolukhin.github.io/type_index/boost/typeind/ctti_type_index.html There is no documentation, so I don't know exactly what to expect from the naming functions (are they working across compilers too?)
4. What is your evaluation of the potential usefulness of the library?
I will replace my use of typeid/type_index/type_info by this library as soon as it is released because I'm working with a lot of shared libraries (both loaded on startup and after) with a cross-platform code base. I use a lot the type informations in particular in type-erasing containers, so I don't want to see strange obscure behaviour in some plateforms/using some compilers but not others.
5. Did you try to use the library? With what compiler? Did you have any problems?
I didn't try to use it yet.
6. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?
I read the documentation, then I looked for the full interface of type_info.
7. Are you knowledgeable about the problem domain?
I use typeid,type_index and type_info a lot for type-erased containers (or other type-erased systems designed for extendability) but I didn't know at all the problems related to these standard features until I read the documentation of the first proposal, which surprised me a lot. So I'm a big user, but not an expert one.
And finally, every review should answer this question:
8. Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion.
YES.