Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Jan Herrmann (jherrmann79_at_[hidden])
Date: 2013-11-21 09:50:12

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?

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

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.

Jan Herrmann