From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28366 invoked by alias); 12 Apr 2002 23:56:02 -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 28345 invoked from network); 12 Apr 2002 23:55:59 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 12 Apr 2002 23:55:59 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16wAtp-0003F8-00 for ; Fri, 12 Apr 2002 19:56:13 -0400 Date: Fri, 12 Apr 2002 16:56:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements Message-ID: <20020412195613.C11562@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> <20020408214935.A14098@nevyn.them.org> <20020410150824.A22581@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/msg00226.txt.bz2 On Fri, Apr 12, 2002 at 03:58:21PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > On Wed, Apr 10, 2002 at 12:31:27PM -0500, Jim Blandy wrote: > > > Daniel Jacobowitz writes: > > > > 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, > > > > }; > > > > > > In other words, replace the sloppy union with a properly discriminated > > > union? I'm for it. > > > > > > But granted that it's important to clearly distinguish between the > > > expanding set of uses we're putting `struct symbol' to, and that > > > extending enum address_class isn't the best idea, how is it better to > > > make this change concurrently with the enclosing environment changes? > > > We could do this change right now. Isn't it basically independent? > > > > Well, no. I was suggesting this for things that are not currently in > > symbols (well, types generally are...). But namespaces are not > > represented at all and fields are in a different structure entirely. > > Okay, I think I see. You're preserving the distinctions implicit in > the existing structures (fields and symbols are separate), > distinguishing types from symbols (i.e. an entry for a typedef would > be an environment_entry whose kind == type_kind, instead of a symbol > with an address class of LOC_TYPEDEF), and positing that namespaces > would be a fourth kind of thing. The `data' field would point to a > `struct type' or a `struct field', or whatever. Yes, that's right. There's also transparent scopes (which might be a special kind of namespace... or not). By that I mean {} enclosed regions with their own local variables. A function belongs to a namespace, a namespace does not enclose a particular range of PCs - but a scope does enclose a particular PC range. Hopefully but not necessarily a single contiguous range. Optimization or explicit .section directives could break it up. > > > Doing it for struct symbol would be a good idea, I think, but a better > > approach would be: > > - start the environments properly, using a new enum. > > - Separate out those things which need to be "different kinds of > > struct symbol", and keep the factoring at the environment level. > > - Look up environment entries, not struct symbol's. That way we can > > have a hope of keeping the right names attached to types, for > > instance. > > By the last point here, are you suggesting that everyone hand around > pointers to `struct environment_entry' objects, rather than pointers > to `struct type', `struct field', etc.? That would lose some > typechecking, and some clarity. If space is the concern, I think I'd > rather see both the environment entry and the symbol/field/etc. have > `name' fields, that perhaps point to the same string. There's a question of correctness, though. Suppose a type is imported into a namespace - we don't want to create a new type for it, but we do want to create a new name for it. I'm not sure what to do. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer