From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13324 invoked by alias); 12 Apr 2002 22:08:03 -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 13242 invoked from network); 12 Apr 2002 22:08:01 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 12 Apr 2002 22:08:01 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id A82055EA11; Fri, 12 Apr 2002 17:08:00 -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> <20020408215921.B14098@nevyn.them.org> <20020409235607.A23587@nevyn.them.org> From: Jim Blandy Date: Fri, 12 Apr 2002 15:08:00 -0000 In-Reply-To: <20020409235607.A23587@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/msg00221.txt.bz2 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? > > 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. > > b) The object representing a namespace keeps around the prefix it > > corresponds to (`std::' or `A::B::' or whatever), so that lookups of > > single name components relative to that namespace can find entries > > stored in either form. > > > > c) For backwards compatibility, the symbol lookup function would check > > for `::' in symbol names, and do a component-by-component lookup. > > We might also want to check for '.', as per Java (in existing gcj > versions, at least). Yes, that's true. > > - Once the producers are all creating data in the new style, remove > > support for it. Now you've got your new data structure, used as an > > opaque datatype. > > And hopefully we'd reach this step, rather than being left with the > mess in the middle. Hopefully! :) > 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.