From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3813 invoked by alias); 10 Apr 2002 19:08:22 -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 3804 invoked from network); 10 Apr 2002 19:08:21 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 10 Apr 2002 19:08:21 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16vNSC-00062u-00; Wed, 10 Apr 2002 15:08:24 -0400 Date: Wed, 10 Apr 2002 12:08:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements Message-ID: <20020410150824.A22581@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> <20020408214935.A14098@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/msg00156.txt.bz2 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. 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. > Getting too technical for this point in the discussion: I like doing > subclassing of structs in C like this: > > struct environment_entry { > const char *name; > enum name_type kind; > }; > > struct field_entry { > struct environment_entry env; > enum field_visibility visibility; > struct type *type; > ... > }; > > Since C guarantees that a pointer to a struct can be safely converted > to a pointer to its first member and back, this is okay. And while > going from superclass to subclass still isn't typesafe, going from > subclass to superclass is. (The down-casting should be hidden in a > function which also checks the tag.) > > But this is just bikeshedding. I like your basic idea, however one > implements it. I actually have a significant gripe with this technique. If we're going to do it, we should use accessor functions (inline or macroized, please...) in both directions. It's very confusing when you see such a thing to have to go check the definition - "is that the first member? Is this reversible?" -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer