Re: [Describe] Review - Part 2: Class types

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-03-14 17:33:11

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. :-)