Re: [boost] [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th

Subject: Re: [boost] [Boost-users] [typeindex v3.0] Peer review begins Mon 21st ends Wed 30th
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2014-04-24 18:26:33

On Sun, Apr 20, 2014 at 8:14 PM, Niall Douglas <s_sourceforge_at_[hidden]>wrote:

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