Boost logo

Boost :

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
returning type_index_'s rather than type_info_t's), right? Two further

* 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
RTTI system (among say others custom-designed by game developers)?
* function_collection and any_collection share 99% of the code with
(the three containers are basically the same with different so-called
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at