From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9199 invoked by alias); 12 Apr 2002 20:58:25 -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 9192 invoked from network); 12 Apr 2002 20:58:23 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 12 Apr 2002 20:58:23 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 332715EA11; Fri, 12 Apr 2002 15:58:22 -0500 (EST) To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> <20020408214935.A14098@nevyn.them.org> <20020410150824.A22581@nevyn.them.org> From: Jim Blandy Date: Fri, 12 Apr 2002 13:58:00 -0000 In-Reply-To: <20020410150824.A22581@nevyn.them.org> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00219.txt.bz2 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. > 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.