From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18478 invoked by alias); 27 Sep 2002 18:28:20 -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 18471 invoked from network); 27 Sep 2002 18:28:20 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 27 Sep 2002 18:28:20 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17v0ma-0000N3-00; Fri, 27 Sep 2002 14:28:12 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17uzqt-0004Gk-00; Fri, 27 Sep 2002 14:28:35 -0400 Date: Fri, 27 Sep 2002 11:28:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: suggestion for dictionary representation Message-ID: <20020927182835.GA16268@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: <20020925125436.GA10407@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00484.txt.bz2 On Fri, Sep 27, 2002 at 01:07:57PM -0500, Jim Blandy wrote: > Daniel Jacobowitz writes: > > > On Tue, Sep 24, 2002 at 10:46:02PM -0500, Jim Blandy wrote: > > > > > > Daniel Berlin writes: > > > > > > > On Tue, 24 Sep 2002, Jim Blandy wrote: > > > > > > > > > > > > > > > Also, for what it's worth, I'm still not ready to completely give up > > > > > > on representing members of classes via a dictionary; that would > > > > > > provide another place where a linear dictionary environment could be > > > > > > useful. > > > > > > > > > > I agree, but it's worth noting that `struct symbol' is 52 bytes long > > > > > on a Pentium, whereas `struct field' and `struct fn_field' are 16 > > > > > bytes long. > > > > > > > > > > Not that that necessarily matters. We know GDB does have memory > > > > > consumption problems, but I have never seen those problems really > > > > > analyzed. > > > > > > > > Um, I have these statistics, but I need to know *exactly* what you want to > > > > know to be able to give them to you. > > > > > > On large C++ programs, how much of a difference would it make if we > > > used `struct symbol' objects (52 bytes long) to represent data members > > > and member functions, instead of `struct field' and `struct fn_field' > > > objects (both 16 bytes long)? > > > > I'm not sure this is the way to go - we could have a dictionary of > > something other than struct symbol, probably. > > Well, for fields, I think you're right. The field list is > intrinsically an ordered thing; a dictionary is not. > > But not for methods, either? Wouldn't it simplify overload set > computation to have methods and ordinary functions represented using > the same structure? Not really. First of all, you never have to deal with both at the same time: void foo(int x) { printf ("Int ver\n"); } class bar { public: void foo (double x) { printf ("Double member ver\n"); } bar() { foo (1); foo(2.); } }; int main() { bar baz; return 0; } Both calls will get the member version. Secondly, getting the type would probably be all of two lines of special case; for the memory savings that sounds pretty good to me. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer