Re: [boost] [poly_collection] Small review

Subject: Re: [boost] [poly_collection] Small review
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2017-05-11 06:26:31

El 09/05/2017 a las 15:46, Ion Gaztañaga via Boost escribió:
> On 09/05/2017 13:39, Joaquin M López Muñoz via Boost wrote:
>> typeid is used extensively throughout the library, both the static
>> (typeid(T)) and the dynamic
>> version (typeid(x)) --the latter only in base_collection and in one 
>> spot in
>> boost/poly_collection/detail/segment.hpp. std::type_index is part of the
>> public interface.
>> Boost.TypeIndex could be in principle optionally used for RTTI-less
>> scenarios, but I don't really
>> know whether this is a common enough / requested scenario.
>
> [...]
>
> Basic examples in the documentation are based on games concepts 
> (sprite, warrior, goblin, ...) and usually in game development builds 
> RTTI is disabled although polymorphism is widely used. My comment is 
> about making the runtime-identification configurable by the user
>
> I can imagine an application where all classes are known and a custom 
> typeid can be generated and stored in the abstract base class of every 
> type, so that it can be retrieved via an inline function, without 
> noticeable run-time overhead. It could just cache a std::type_info 
> pointer.
>
> I think a lot of game engines use their own RTTI framework that could 
> be easily plugged into PolyCollection (maybe as an additional 
> TypeIdTraits template parameter). Something like:
>
> class typeid_traits
> {
>    typedef /**/ type_info_t;
>    typedef /**/ type_index_t;
>
>    template<class T>
>    static type_info_t typeid_of(T *p);
>
>    //Usage: const type_info_t &ti = typeid_of<MyClass>();
>    template<class T>
>    static type_info_t typeid_of();
> };
>
> type_index_t should be constructible from type_info, hashable and 
> comparable.
>
> This type of abstraction could support Boost.TypeInfo and many other 
> approaches. Anyone sees this customization useful? 

I'm no expert in game development so I can't really assess how common 
this custom
typeid thing is. In any case, if the community deems this worth 
including I can
definitely work on it; one thing I don't get about your proposed design 
is the
insistence on the type_info_t/type_index_t distinction: to the best of 
my knowledge
std::type_index should have been what typeid() returned and was added as 
a patch
over less useful typeinfo so as not to break backwards compatibility, so 
here we can just
as well learn from the past and simply use type_index_t (with typeid_of 
directly
returning type_index_'s rather than  type_info_t's), right? Two further 
doubts:

* How does this combine with usage of Boost.TypeIndex? I mean, can usage of
Boost.TypeIndex be shoehorned into this typeid_traits framework as an 
alternative
RTTI system (among say others custom-designed by game developers)?
* function_collection and any_collection share 99% of the code with 
base_collection
(the three containers are basically the same with different so-called 
"model"
policies), so this traits thing could extend almost automatically to 
them. But I fail
to see what the use of it would be. Except when the selected traits are 
those of
Boost.TypeIndex... well, possibilities abound here.

Joaquín M López Muñoz