Date: Mon, 31 Jan 2022 11:59:02 -0500
> On Jan 31, 2022, at 11:39 AM, Peter Dimov <pdimov_at_[hidden]> wrote:
>
> Daveed Vandevoorde wrote:
>> Note that “a base class” in C++ is not the same as “the type of a base class”. A
>> base class is closer to “a data member”: It describes a subobject designation.
>
> This reminds me of an observation I had: it would have been nice if we could
> actually form pointer to member to a specific base class, so that we can then
> reflect it.
I can see how that could be useful: Extend the notion of pointer-to-member to also be able to designate bases.
(That’s orthogonal to reflection though.)
> Because as-is, if you have two bases of the same type, there's no way
> you can differentiate between them just by their type.
Even “not as is”: It’s an ambiguous question to ask?
That said, there is an interesting reflection-design topic here.
Right now, bases_of returns a span only describing direct and virtual bases. It’s not yet said in the paper, “virtual bases” here is from the perspective of the operand type being the complete type. E.g.:
struct V {};
struct B { int i; };
struct C: B, virtual V { int j; };
struct D: C { int k; };
Here bases_of(^D) will contain two entries: One for the direct base of type C and one for the virtual base of type V. For the latter, if you query the offset of that virtual base, for example, you’ll get the offset within a complete object of type D (i.e., if you had started with bases_of(^C) you might have gotten a different offset).
Another option might have been to also include a representation of the indirect base of type B (i.e., B-in-C-in-D). The reason that’s not currently proposed is that I believe not all compilers maintain such a representation, but perhaps its worth considering anyway?
Daveed
>
> Daveed Vandevoorde wrote:
>> Note that “a base class” in C++ is not the same as “the type of a base class”. A
>> base class is closer to “a data member”: It describes a subobject designation.
>
> This reminds me of an observation I had: it would have been nice if we could
> actually form pointer to member to a specific base class, so that we can then
> reflect it.
I can see how that could be useful: Extend the notion of pointer-to-member to also be able to designate bases.
(That’s orthogonal to reflection though.)
> Because as-is, if you have two bases of the same type, there's no way
> you can differentiate between them just by their type.
Even “not as is”: It’s an ambiguous question to ask?
That said, there is an interesting reflection-design topic here.
Right now, bases_of returns a span only describing direct and virtual bases. It’s not yet said in the paper, “virtual bases” here is from the perspective of the operand type being the complete type. E.g.:
struct V {};
struct B { int i; };
struct C: B, virtual V { int j; };
struct D: C { int k; };
Here bases_of(^D) will contain two entries: One for the direct base of type C and one for the virtual base of type V. For the latter, if you query the offset of that virtual base, for example, you’ll get the offset within a complete object of type D (i.e., if you had started with bases_of(^C) you might have gotten a different offset).
Another option might have been to also include a representation of the indirect base of type B (i.e., B-in-C-in-D). The reason that’s not currently proposed is that I believe not all compilers maintain such a representation, but perhaps its worth considering anyway?
Daveed
Received on 2022-01-31 16:59:03