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: Boris Rasin (boris_at_[hidden])
Date: 2015-05-05 11:17:51

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?