Re: [boost] interest in structure of arrays container?

Subject: Re: [boost] interest in structure of arrays container?
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2016-10-16 14:46:42

On 10/16/2016 3:28 AM, Andreas Schäfer wrote:
> Hey,
>
> On 00:36 Sun 16 Oct     , Michael Marcin wrote:
>> Indeed this works well for a fixed sized dataset.
>> It doesn't have the wasted duplicated information that a tuple of
>> std::vectors has.
>> It still doesn't provide an interface to query the soa directly for an
>> iterator or size etc.
>>
>> Both a fixed-sized and dynamic-growth container are useful.
>> Although I tend to need dynamic growth more often.
>
> I've implemented your example using the soa_grid from LibFlatArray:
>
> ================================= 8< ============================
>
> #include <libflatarray/flat_array.hpp>
>
> class citizen
> {
> public:
>     std::string first_name;
>     std::string last_name;
>     int salary;
>     int age;
> };
>
> LIBFLATARRAY_REGISTER_SOA(
>     citizen,
>     ((std::string)(first_name))
>     ((std::string)(last_name))
>     ((int)(salary))
>     ((int)(age)))
>
> int main()
> {
>     LibFlatArray::soa_grid<citizen> citizens(300, 1, 1);
>     long accumulator = 0;
>
>     citizens.callback([&citizens, &accumulator](auto i) {
>             for (; i.index() < citizens.dim_x(); ++i) {
>                 accumulator += i.salary();
>             }
>         });
>     int average = accumulator / citizens.dim_x();
>
>     return 0;
> }
>
> ================================= 8< ============================
>
> The size of the soa_grid can be chose at runtime, but it might not be
> a good match for the use case you describe: it's essentially 3D and
> hence doesn't support push_back() and friends. On the other hand,
> LibFlatArray::soa_array is 1D and behaves much more like std::vector,
> but it also has a maximum size that's fixated at compile time.

Thanks for clarifying.

>
> Would something like an soa_vector, that's resizable at runtime and
> behaves much like a std::vector better suit your needs?
>

Yes exactly that.
I would also strongly prefer a tuple-like variadic template interface to 
a macro interface.