|
Boost : |
Subject: Re: [boost] tuple_vector (was poly_collection)
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2014-08-24 18:55:11
Thijs Van Den Berg wrote:
>>> The usage should be as close to std::vector as possible, so e.g.:
>>>
>>> |tuple_vector<std::tuple<T1, T2, T3, ...>> v;
>>> v.resize(count);
>>>
>>> for (int i = 0; i < count; ++i)
>>> {
>>> T1 t = std::get<0>(v[i]);
>>> std::get<0>(v[i]) = ...;
>>> }|
>>>
>>>
>>> A thing worth noticing is that the tuple_vector's reference type is a
>>> tuple of references:
>>>
>>> std::tuple<T1&, T2&>
>> Could also be any proxy type, that's more flexible.
>> The important aspect is that tuple_vector's reference cannot be value_type&.
>>
> Ive been looking at heterogenous containers without type erasure using tuple_vectors. My solution was to define an invoke function that allowed you to manipulate all (types) of elements in the container.
>
> In this example I have a set of shapes in the tuple_vector like circle, rectangle
and a set of operations like move, rotate that I invoke on all elements.
>
> Here is the C++14 code snippet:
> http://pastebin.com/s7dBfWDX
AFAIU your approach seems to be more like the static poly_collection
mentioned by Joaquin since the purpose is to store the same types of
objects in the same containers and then iterate over them all. So
internally it looks like this:
v1: |Pt|Pt|Pt|Pt|
v2: |Line|Line|
v2: |Rect|
Iteration(Flattening): |Pt|Pt|Pt|Pt||Line|Line||Rect|
As Ion wrote in one of the emails, "a container that is not a sequence,
unordered but not associative".
My container's purpose is to separate hot and cold data. In my
tuple_vector there are the same numbers of elements stored in each
vector. The i-th elements in each vector are related with each other.
It's possible to access one element or all of them. The idea is to make
the interface as close to the std::vector<std::tuple<...>> as possible.
Internally it looks like this:
v1: |D1|D1|D1|D1|
v1: |D2|D2|D2|D2|
v1: |D3|D3|D3|D3|
^
|
<D1,D2,D3>
Regards,
Adam
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk