2013/11/21 Jan Herrmann
Only from reading documentation I have a few questions:
1. In http://apolukhin.github.io/type_index/boost_typeindex/ examples.html#boost_typeindex.examples.getting_through_the_inheritance_is written that polymorphic types can't be identified without RTTI. It should be possible for a library user to make his types compatible with Boost.TypeIndex to identify them. For example he can return boost::type_info from a virtual function inside each class:
struct A { virtual ~A(){} virtual boost::type_info const& get_boost_type_info() const { return boost::type_id<A>()); } }; struct B: public A { virtual boost::type_info const& get_boost_type_info() const { return boost::type_id<B>()); } }; struct C: public B { virtual boost::type_info const& get_boost_type_info() const { return boost::type_id<C>()); } };
Boost.TypeIndex should provide a way to use such methods inside boost::type_id_rtti_only. Is something like this planned?
This looks like a *very* good addition, thanks for the idea! This will be implemented as soon as possible (before the next review).
2. As far as I understand almost everything inside the library is build on top of string comparison. All these strings are available at compile time. Are there plans to make boost::template_info a literal type? It would help with metaprogramming to have a system representing types with the same set of operations and behavior at compile time and run time (I think of sorting classes at compile time, store boost::template_info of them in an array and use some binary search at run time).
This can be interesting. That feature will be implemented, however I do not see how this could be possible to do in C++03/C++98.
3. What are he exact reasons for storing types with const, volatile and reference in boost::type_id_with_cvr? As long as there is no way to query this information and remove it at run time I think it would better users store them together with type_index if the need this feature. It could result in hard to find errors when users use type_if_with_cvr in one module and not expecting them in another.
This is done for libraries that use type erasure technique a lot. Sometimes
there may be a need to store those modifiers (there was an example in
examples section for that case:
http://apolukhin.github.io/type_index/boost_typeindex/examples.html#boost_ty...)
There must be no problems with mixing boost::type_id_with_cvr and
boost::type_id. If there are no modifiers, result will be the same:
boost::type_id_with_cvr<int>() == boost::type_id<int>()
boost::type_id_with_cvr