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