From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10819 invoked by alias); 10 Apr 2002 17:31: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 10785 invoked from network); 10 Apr 2002 17:31:30 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 10 Apr 2002 17:31:30 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id C3D085EA11; Wed, 10 Apr 2002 12:31:27 -0500 (EST) To: Daniel Jacobowitz Cc: gdb@sources.redhat.com, Benjamin Kosnik , Daniel Berlin 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> From: Jim Blandy Date: Wed, 10 Apr 2002 10:31:00 -0000 In-Reply-To: <20020408214935.A14098@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/msg00152.txt.bz2 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? 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.