From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15994 invoked by alias); 22 Aug 2002 22:24:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 15987 invoked from network); 22 Aug 2002 22:24:21 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 22 Aug 2002 22:24:21 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g7MMOJP15892; Thu, 22 Aug 2002 15:24:19 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Daniel Jacobowitz Cc: gdb Subject: Re: TYPE_VPTR_BASETYPE and TYPE_DOMAIN_TYPE References: <20020822204648.GA31816@nevyn.them.org> Cc: carlton@math.stanford.edu Content-Type: text/plain; charset=US-ASCII From: David Carlton Date: Thu, 22 Aug 2002 15:24:00 -0000 In-Reply-To: <20020822204648.GA31816@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 X-SW-Source: 2002-08/txt/msg00270.txt.bz2 In article <20020822204648.GA31816@nevyn.them.org>, Daniel Jacobowitz 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