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 06:12:12

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.