Andrzej Krzemienski wrote: ...
It even works when base classes have members with same names:
struct X { int a; };
struct Y { int a; };
struct Z : X, Y { int b; }; ... 5. What is the use case for modifier mod_hidden? I cannot think of any situation where I would need it.
If you change the name of `Z::b` above to `a`, it will hide the two `a` members in X and Y, so they won't be included in mod_inherited unless mod_hidden is also passed. Whether you'd want them to be depends on why do you want all the members; when doing RPC you don't want the hidden functions, for instance. But if for some (layout?) reasons you want all the data members, you do want the hidden members.
7. Modifier mod_virtual works unintuitively. It does not affect the filtering in describe_bases<>. It is only used for decorating the list elements. Maybe the docs should be more explicit about what it is used for. Again, is there a use case for this?
mod_virtual is necessary for the implementation of mod_inherited for base classes (virtual bases of the same type must only be returned once.) Since the library has to compute it anyway, I might as well return it to the user. My original design (which was about a compiler implementation of these reflection facilities) had more such output-only "modifiers", such as mod_final and mod_overridden. These, along with mod_virtual, were supposed to be returned in member function descriptors - the compiler knows all this and we can't get it in any other way, so why not return it. In the library implementation, only mod_virtual for bases remained. :-)