TYPE_VPTR_BASETYPE and TYPE_DOMAIN_TYPE

[David Carlton]

In article <20020822204648.GA31816@nevyn.them.org>, Daniel Jacobowitz <drow@mvista.com> writes:

> As I understand it TYPE_DOMAIN_TYPE applies to methods, but
> TYPE_VPTR_BASETYPE definitely only has meaning for structures.

That make sense.

> Probably just the comment needs to be updated.  Now it's:
>      For types that are pointer to member types (TYPE_CODE_MEMBER),
>      VPTR_BASETYPE is the type that this pointer is a member of.

>      For method types (TYPE_CODE_METHOD), VPTR_BASETYPE is the aggregate
>      type that contains the method.

Right, I was thinking of adding at the beginning of that comment a
note that the field can be accessed via either TYPE_VPTR_BASETYPE or
TYPE_DOMAIN_TYPE and then replacing the VPTR_BASETYPEs in the above
comments by DOMAIN_TYPEs.  Or something like that.

> Can you think of any time where having both would be useful?

Not offhand.  Having said that, if the two uses are conceptually
different enough that we want to maintain two different public
interfaces to the vptr_basetype member, then I suppose there's a third
possibility: replace the current vptr_basetype member by a union with
two members, both of which are struct type *'s, but just with
different names (vptr_basetype and domain_type).

But I guess using a union like that would be silly: a real distinction
without a difference, given that users could still set the member via
vptr_basetype and access it via domain_type or vice-versa.  And
somehow I don't think that it would be considered acceptable to
rewrite GDB in C++ in order to put some teeth behind this
distinction...

David Carlton
carlton@math.stanford.edu