Provide AoS access to SoA - c++

Question

I have data laid out in memory in a Structure of Arrays (SoA) or Sturcture of Pointers (SoP) form, and have a way to access that data as though it were laid out in Array of Structure (AoS) form -- code given below.
However, I am not too happy about use of struct AoS_4_SoP -- although this struct appears to use templates, it is not really generic since, for example, foo and bar are hard-coded inside it.
Two questions/requests:
1) For read-write performance, is AoS access provided as good as the direct SoA access?
2) What would a more generic scheme be? (I have seen quamrana's code here, but it hasn't helped.)
struct SoP{ // Structure of Pointers
int *foo{ nullptr };
double *bar{ nullptr };
SoP( int *xi, double *xd ):foo(xi), bar(xd){};
};
struct SoR{ // Structure of References
int &foo;
double &bar;
SoR( int &xi, double &xd ):foo(xi), bar(xd){};
};
template< typename T, typename S >
struct AoS_4_SoP {
AoS_4_SoP( T *x ) : p( x ){};
T *p;
S operator[](std::size_t idx) const { return { p->foo[idx], p->bar[idx] }; }
const S operator[](std::size_t idx) const { return { p->foo[idx], p->bar[idx] }; }
};
Here's a main() showing the use of the above:
int main()
{
std::vector< int > ibuf{ 11, 22, 33, 44 };
std::vector< double > dbuf{ 0.11, 0.22, 0.33, 0.44 };;
SoP x_sop( ibuf.data(), dbuf.data() );
ibuf.at(2) = 333;
std::cout << "Access via SoP syntax:\n "
<< x_sop.foo[2]
<< " "
<< x_sop.bar[2] << std::endl;
AoS_4_SoP<SoP, SoR> xacc( &x_sop );
std::cout << "Access via AoS syntax:\n "
<< xacc[2].foo
<< " "
<< xacc[2].bar << std::endl;
// show write access via SoA syntax
ibuf.at(2) = 3333;
dbuf.at( 2 ) = 0.333333; // will get overwritten below
xacc[2].bar = 0.3333;
std::cout << "Values written via SoP, read via SoP:\n "
<< x_sop.foo[2]
<< " "
<< x_sop.bar[2] << std::endl;
// show write access via AoS syntax
xacc[2].foo = 333333;
dbuf.at( 2 ) = 0.3333333333; // will get overwritten below
xacc[2].bar = 0.333333;
std::cout << "Values written via AoS, read via AoS:\n "
<< xacc[2].foo
<< " "
<< xacc[2].bar << std::endl;
}
Above code can be compiled via:
// x86_64-w64-mingw32-g++.exe -D_WIN64 -Wall -Wextra -Werror -std=c++11 -O3 -static-libgcc -static-libstdc++ aossoa.cc -o aossoa.exe
and results in the following output:
Access via SoP syntax:
333 0.33
Access via AoS syntax:
333 0.33
Values written via SoP, read via SoP:
3333 0.3333
Values written via AoS, read via AoS:
333333 0.333333

Answer 1

I think this template will work.
template<class T, class U, class D, class S>
struct Accessor {
T* p;
U* (T::*pFirst);
D* (T::*pSecond);
S operator[](size_t index) {
return {(p->*pFirst)[index], (p->*pSecond)[index]};
}
Accessor(T* p_, U * (T::*pF), D * (T::*pS)): p(p_), pFirst(pF), pSecond(pS) {}
};
void main() {
std::vector< int > ibuf{ 11, 22, 33, 44 };
std::vector< double > dbuf{ 0.11, 0.22, 0.33, 0.44 };;
SoP x_sop(ibuf.data(), dbuf.data());
Accessor<SoP, int, double, SoR> aos(&x_sop, &SoP::foo, &SoP::bar);
aos[0].foo;
}
Now the template Accessor knows nothing about the names of the members of T.
At least it compiles under VS2015

Answer 2

Here's my adaptation of quamrana's solution for the "inverse" use case (SoA access for AoS):
template<class T, class S, class M0, class M1>
struct Accessor2{
T* p;
M0 m0;
M1 m1;
S operator[](std::size_t idx) { return { m0[idx], m1[idx] }; }
const S operator[](std::size_t idx) const { return { m0[idx], m1[idx] }; }
Accessor2(T* x, M0 p0, M1 p1): p(x), m0(p0), m1(p1){}
};
template< typename T, typename S >
struct AoS_4_SoP : public Accessor2<T, S, decltype(T::foo), decltype(T::bar)>
{
#ifndef COMPILER_CAN_INFER_PARENT_CLASS_TEMPLATE_SPECIFICATION
AoS_4_SoP(T *x) : Accessor2<T, S, decltype(T::foo), decltype(T::bar)>
(x, x->foo, x->bar ){}
#else
AoS_4_SoP(T *x):Accessor2(x, x->foo, x->bar ){}
#endif
};
Regarding the #ifndef COMPILER_CAN_INFER_PARENT_CLASS_TEMPLATE_SPECIFICATION, the compiler I am using viz, g++ 6.2.0 (x86_64_6.2.0_posix_seh_rt_v5_rev1/mingw64/bin/x86_64-w64-mingw32-g++.exe) is unable to infer the parent class' template specification. But, as Lightness Races in Orbit says on this page: the base's injected-class-name ought to be sufficient information for the compiler.