From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8475 invoked by alias); 9 Apr 2002 01:49:35 -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 8467 invoked from network); 9 Apr 2002 01:49:32 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 9 Apr 2002 01:49:32 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16uklL-0003jJ-00; Mon, 08 Apr 2002 21:49:35 -0400 Date: Mon, 08 Apr 2002 18:49:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com, Benjamin Kosnik , Daniel Berlin Subject: Re: C++ nested classes, namespaces, structs, and compound statements Message-ID: <20020408214935.A14098@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com, Benjamin Kosnik , Daniel Berlin References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00108.txt.bz2 On Mon, Apr 08, 2002 at 07:19:14PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > How about -containing- `struct fields', instead of replacing? i.e. let > > the name search happen in the `struct environment', as before, but the > > data items would be fields (could be indicated in a flag in the > > environment, with a pointer to the type or symbol for the enclosing > > structure). I don't think turning members into symbols is a good idea. > > I admit the idea of using `struct symbol' for fields as well as > variables is pretty weird. Here's the rationale: > > First, keep in mind that `struct symbol' is sort of a `messy union': > it's used for a lot of distinct purposes, and it contains all the > members any of those purposes might need. The `struct symbol' > representing a declaration like `struct A' doesn't need its > ginfo.value field. The `struct symbol' representing a local variable > doesn't need its `bfd_section' field. (I'm not saying this is a great > way to do things; but it is the way it's done now.) Sure. But I think this is a chance (if we want one) to move in a different direction. We'd have to work out the details, but I envision something like this (names made up as I go along): struct environment_entry { const char *name; enum name_type kind; void *data; } enum name_type { type_kind, field_kind, symbol_kind, namespace_kind, }; Some duplication between symbol_kind and field_kind that would need to be decided on, and there's probably other useful kinds. There could even be a subtype in there if we found it convenient. For instance: /* For classes. */ enum field_kind { normal_field, static_field, base_class, /* Probably not this one, actually. Better kept in the type? */ member_function, static_member_fn, /* Might or might not be necessary. */ }; Then we don't need to have a dummy symbol for every type, etc. It would keep searching a little more straightforward. IMVHO. There's plenty of details I haven't thought about how to fit in. Like, the protections on a member type. Perhaps the environment really should dictate a structure for every member of the environment, opaquely. We have some wiggle room here. There's also a question of how many "kinds" of lookup situations we have - implicit vs. explicit members, for instance. Some inherit one way, some another, so we'd need to have separate lookup functions. Categorizing by an enum is all good. Reusing address classes, though, I'm more suspicious of. Does that make sense? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer