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 12:24:29

On 21.11.2013 16:57, Antony Polukhin wrote:
> 2013/11/21 Jan Herrmann <jherrmann79_at_[hidden]>
>
>> 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).

I think some macros can make it very easy to implement this for clients.

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

Yes it's only possible with constexpr, but I see your work as a part for 
building better TypeIndex like systems. Users should be able to build 
their own RTTI system with information about types they need. For 
example a RTTI system could provide information about size and alignment 
or provide a type erased clone implementation (from a void* to void* 
with same type).

>
>
>> 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_typeindex.examples.exact_type_match_storing_type_wi)
>
> 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<user_defined>() == boost::type_id<user_defined>()
>
> Or am I missing some use case?
>

I see type erasure in conjunction with type recovery. And I think these 
bits of information are not worth. If it is possible that somebody calls 
boost::type_id_with_cvr in one module other modules which needs to probe 
for types have to check every type 12 times (2 (const) x 2 (volatile)  x 
3(no ref, ref, rvalue rev). Think of implementing a ad-hoc visitor 
(http://www.drdobbs.com/generic-programmingtypelists-and-applica/184403813) 
with TypeIndex and void*.
When implementing a function which only needs a const value client has 
to probe for const and non-const types only to get a const value out of it.
I'm not sure whether volatile should be considered. For example no 
container in std has overloads for volatile access to elements, but they 
are all const correct.
References are another problem. In case of type erased storage they are 
very distinct form values but sometimes they should be used like values. 
If I remember correctly there where long debates about std::optional and 
references in isocpp.proposals or general this year. Arguments could be 
same here.

I wouldn't feel comfortable to work with type properties without being 
able to query them. Type recovery is hard enough.

But if somebody needs these information there are a few ways. One would 
be to align type_index at a 8 Byte boundary so users could store 
pointers and would have 4 bits. The other option is to let users build 
their own facilities via composition of some state variable and type_index.

Jan Herrmann