Re: [boost] [poly_collection] User-defined polymorphism model

Subject: Re: [boost] [poly_collection] User-defined polymorphism model
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2017-05-14 09:35:22

On 14/05/2017 9:51, Joaquín M López Muñoz via Boost wrote:
>> I have several questions on this polymorphism model.
>>
>> 1) Wouldn't be a good idea to make this model-based polymorphism
>> (or a refined one) public? Maybe the current model needs more work
>> to support additional polymorphism models. Of course requirements
>> for each operation in a model should be detailed. A correct
>> abstraction to define user-provided polymorphism models is hard but
>> this seems really a great feature that makes this library more
>> valuable for users.
>
> I'd be really conservative here and withhold such a big move until
> real use cases are found. The problem is once this is made public the
> design of the lib becomes effectively frozen.

Right. We'd need more to test more polymorphism models in order to 
deduce a more generic model. Noted for a future improvement.

>> Current implementation uses two segment types: split_segment
>> (stores Concrete types and generic value_type's in two separate
>> vectors) and packed_segment (stores ConcreteTypes which already
>> contain value_type's as a subobject). function_collection and
>> any_collection use the first segment, base_collection uses the
>> second.
>>
>> Why are different segment types needed? Can't we store value_types
>> and ConcreteTypes in a struct and use only one type of segment? If
>> this is possible, I guess iteration performance would be improved
>> for function_collection and any_collection. Model definition could
>> be simplified.
>>
>
> I tried using packed_segment with function_collection and
> any_collection, profiled and found split_segment is faster:
> basically, it gets you more values per cache line.

Ok, now I see it. Since poly_collection optimizes processing and not 
space or other operations, split_segment seems a good choice as objects 
are tightly packed and all additional data is stored in another segment. 
packed_segment is an optimization when value_type is already stored 
inside the object (like a base class). Makes sense.

>> On the other hand, if the sequence type can be left out of the
>> model definition, the underlying sequence type (change vector with
>> deque, small vector or any other) could be made configurable. Would
>> this be useful for users?
>>
>
> This was also proposed by Thorsten, please see my answer there.

Right. Maybe the least intrusive approach is to require element 
contiguity so something like small-vector could be used. But I agree 
this is not an essential feature.

Best,

Ion