Re: [boost] Interest in a container which can hold multiple data types?

Subject: Re: [boost] Interest in a container which can hold multiple data types?
From: TONGARI J (tongari95_at_[hidden])
Date: 2015-05-05 12:29:53

2015-05-05 23:17 GMT+08:00 Boris Rasin <boris_at_[hidden]>:

> On 5/5/2015 1:12 PM, TONGARI J wrote:
>
>> 2015-05-05 17:21 GMT+08:00 Boris Rasin <boris_at_[hidden]>:
>>
>>  On 5/5/2015 9:31 AM, Thijs (M.A.) van den Berg wrote:
>>>
>>>  tuple_vector<Point, Line, Rectangle, Circle> shapes;
>>>>
>>>>> shapes.push_back(Point{1.0, 1.0} );
>>>>>>
>>>>>>  This is neat, but it' not quite the same thing. Unlike
>>>>> std::vector<boost::any>, your tuple_vector does not organize objects
>>>>> into
>>>>> strictly linear arrangement. Using your example, there is no way to
>>>>> draw
>>>>> shapes in the order they were inserted into container.
>>>>>
>>>>>   Good point! So it loses overall ordering, only preservers it at the
>>>>>
>>>> type level. The reason is that objects gets stored in linear memory per
>>>> type.
>>>>
>>>>  One could conceivably add another internal container to maintain
>>> overall
>>> index. But than again, is such tuple_vector<Point, Line, Rectangle,
>>> Circle>
>>> really better than std::vector<boost::variant<Point, Line, Rectangle,
>>> Circle>>? It would use less memory per object when some stored types are
>>> smaller than others, and in some circumstances these savings would exceed
>>> overhead of multiple internal containers and an additional index
>>> container.
>>> Any other advantages?
>>>
>>
>> If the data sequence shows some affinity, I guess an ordered
>> tuple_vector-based sequence can provide some performance benefit in
>> traversal (with some crafted for_each method).
>>
>> That is, a sequence of [AAABBB] may be traversed faster than [ABABAB] for
>> such a container, and I believe in the later case such that the types are
>> uniformly distributed, vector<variant> will perform better.
>>
>
> Why would a sequence of [AAABBB] be traversed faster for such a container
> compared to vector<variant>? Especially if it would need additional look up
> in internal index container on every iteration?

The point is bulk operation. The internal could use some interval/span
based structure for the indices , e.g. (A, 3), (B, 3) for [AAABBB].
Traversing the container in order then collapses to tight loops for
consecutive data of the same type, that is, one `switch` for multiple
elements, so the overhead could be amortized, while for vector<variant>,
there's always one switch for one element.