From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23004 invoked by alias); 24 Sep 2002 06:50:33 -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 22995 invoked from network); 24 Sep 2002 06:50:31 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 24 Sep 2002 06:50:31 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g8O6ZUC23979; Tue, 24 Sep 2002 01:35:30 -0500 Date: Mon, 23 Sep 2002 23:50:00 -0000 Message-Id: <200209240635.g8O6ZUC23979@zenia.red-bean.com> From: Jim Blandy To: david carlton CC: gdb@sources.redhat.com Subject: Re: suggestion for dictionary representation X-SW-Source: 2002-09/txt/msg00367.txt.bz2 > 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. All the memory could be in physnames, for all we know. But I'd want to have some sense of the impact before I made the change. (Perhaps a heavy C++ user could stick a `char foo[52 - 16]' at the end of `struct field' and `struct fn_field', and tell us how that goes.) An intermediate step would be to simply add a `struct dictionary *' to `struct cplus_struct_type'. We could use that right off the bat for nested classes, typedefs, and enums. We could then migrate other stuff over there incrementally.