C++ Logo

sg7

Advanced search

Re: [isocpp-sg7] SG7 late paper P3493R0 - Ruminations on reflection and access

From: Peter Dimov <pdimov_at_[hidden]>
Date: Mon, 11 Nov 2024 17:37:00 +0200
Ville Voutilainen wrote:
> For an illustrative one, it's far too easy to perform a SoA<=>AoS
> transformation on a type that doesn't actually expose those types and
> cardinalities, when most of your types are actually all-public structs and then
> you manage to throw not-all-public classes into the mix.

I agree that it's easy to write a mostly-working AoS->SoA transformation
that only handles structs properly, and that the failure mode of using
"get accessible nonstatic data members" is better than the failure mode
of using "get all nonstatic data members".

In the typical case of a type with only private data members, this would
result in an empty SoA type.

Of course, you can see the question "do you really want your transformation
to depend on the place where you happen to invoke it" coming, right?

This example is representative for a class of uses where what you really
want is not "only do this for the accessible members", and not even
"only do this for the public members", but "only do this for types that
only have public members, reject the rest".

In addition, you also need to take care to reject unions, for which filtering
by accessibility won't help you at all, and, in the AoS->SoA case, bitfields.

So filtering by accessibility, while somewhat of an improvement in catching
accidental misuses, isn't really what one would ideally want.

Of course, if we really want to do this properly, one might argue that the
proper transformation of vector<X> for this

class X
{
public:
    int a;
protected:
    int b;
private:
    int c;
};

isn't this

struct X'
{
    vector<int> a';
}

but rather this

class X'
{
public:
    vector<int> a';
protected:
    vector<int> b';
private:
    vector<int> c';
};

Others might argue, in contradiction to the above, that transforming
vector<complex<float>> into a struct is a perfectly cromulent use case.

TL;DR if we want to prevent accidental misuses of this (unfortunately
quite common) sort, what we need is not a function to get the accessible
nonstatic data members, but a function that gets the nonstatic data
members of a struct-like type, and fails for non-struct-like types.

Received on 2024-11-11 15:37:06