TYPE_VPTR_BASETYPE and TYPE_DOMAIN_TYPE

TYPE_VPTR_BASETYPE and TYPE_DOMAIN_TYPE

[David Carlton]

What's the deal with TYPE_VPTR_BASETYPE and TYPE_DOMAIN_TYPE being the
same thing?  Did struct main_type once contain two different members
that got merged?  It seems like a potential source of confusion right
now (it certainly slowed me down when tracking down a recent bug).

It seems like there are two obvious fixes.  If we're not planning to
split them back apart in the near future, then either
TYPE_VPTR_BASETYPE or TYPE_DOMAIN_TYPE should be elimininated.  If we
want to leave open the possibility of splitting them back apart,
however, then the comment before the definition of the vptr_basetype
field should be emended to say when you're supposed to use
TYPE_VPTR_BASETYPE to access it and when you're supposed to use
TYPE_DOMAIN_TYPE to access it.  (And, of course, all uses should be
checked to make sure they follow that recommendation.)

I'd be happy to make either of those changes, if people agree that one
of them is a good idea.

David Carlton
carlton@math.stanford.edu

Re: TYPE_VPTR_BASETYPE and TYPE_DOMAIN_TYPE

[Daniel Jacobowitz]

On Thu, Aug 22, 2002 at 01:38:25PM -0700, David Carlton wrote:
> What's the deal with TYPE_VPTR_BASETYPE and TYPE_DOMAIN_TYPE being the
> same thing?  Did struct main_type once contain two different members
> that got merged?  It seems like a potential source of confusion right
> now (it certainly slowed me down when tracking down a recent bug).
> 
> It seems like there are two obvious fixes.  If we're not planning to
> split them back apart in the near future, then either
> TYPE_VPTR_BASETYPE or TYPE_DOMAIN_TYPE should be elimininated.  If we
> want to leave open the possibility of splitting them back apart,
> however, then the comment before the definition of the vptr_basetype
> field should be emended to say when you're supposed to use
> TYPE_VPTR_BASETYPE to access it and when you're supposed to use
> TYPE_DOMAIN_TYPE to access it.  (And, of course, all uses should be
> checked to make sure they follow that recommendation.)
> 
> I'd be happy to make either of those changes, if people agree that one
> of them is a good idea.

As I understand it TYPE_DOMAIN_TYPE applies to methods, but
TYPE_VPTR_BASETYPE definitely only has meaning for structures. 
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.

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

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: 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