From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15799 invoked by alias); 12 Apr 2002 23:32:07 -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 15784 invoked from network); 12 Apr 2002 23:32:01 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 12 Apr 2002 23:32:01 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16wAWd-00030z-00 for ; Fri, 12 Apr 2002 19:32:15 -0400 Date: Fri, 12 Apr 2002 16:32:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements Message-ID: <20020412193215.A11562@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> <20020408215921.B14098@nevyn.them.org> <20020409235607.A23587@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/msg00224.txt.bz2 On Fri, Apr 12, 2002 at 05:08:00PM -0500, Jim Blandy wrote: > > Daniel Jacobowitz writes: > > As much of a pain as they are, I recommend a CVS branch for this. Then > > we can see how it comes together with some history and a little less > > destabilization. We still need to know where we're going first, of > > course. > > So you're suggesting that we do all the work first on a branch, and > then once we've got that the way we want, we merge it piece-wise into > the trunk? Probably wisest. > > > a) The symbol table stores names either way: with an explicit > > > namespace tree, or with qualified names sitting directly in the > > > symbol table. (When I say "namespace", please understand that to > > > also include classes, etc.) Any given symbol is stored only one > > > way or the other, but any given symbol table can hold a mix of > > > symbols in each form. Symbols stored in the explicit tree would > > > have a `fully_qualified_name' field, so symtab clients expecting > > > to see fully qualified names would still get them. > > > > OK so far... we might want to take the path of least resistence, leave > > the name fully qualified, and add an unqualified_name. > > Sure. I think this is the way to go, then. > > I like it. Who wants to start? :) We probably want to start with > > interfaces, and then see where we need to go from there. > > If I write up a concrete proposal for this, I think my keepers will > let me spend time on it. Sure, let's draft some interfaces. Great! -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer