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
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk