From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5527 invoked by alias); 8 Apr 2002 23:48:10 -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 5517 invoked from network); 8 Apr 2002 23:48:08 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 8 Apr 2002 23:48:08 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16uirs-0002m9-00 for ; Mon, 08 Apr 2002 19:48:12 -0400 Date: Mon, 08 Apr 2002 16:48:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements Message-ID: <20020408194812.A10572@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <20020406044204.245E45EA11@zwingli.cygnus.com> 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/msg00104.txt.bz2 On Mon, Apr 08, 2002 at 06:29:37PM -0500, Jim Blandy wrote: > > Jim Blandy writes: > > As a half-baked idea, perhaps a `struct environment' object would have > > a list of other `struct environment' objects you should search, too, > > if you didn't find what you were looking for. We could use this to > > search a compound statement's enclosing scopes to find bindings > > further out, find members inherited from base classes, and resolve C++ > > `using' declarations. > > >From the discussion, it's pretty clear that this idea is, indeed, > half-baked. While the general idea of "stuff from over there is > visible here, too" does recur in the different contexts, there are so > many subtle differences in exactly what it means that I'm > uncomfortable having generic code try to handle it. I have the > feeling that it would become populated with "if we're doing C++ > inheritance, do this; but if we're stepping out to an enclosing > compound statement, do this; ..." garbage. It's better to let the > context implement the right semantics itself. > > However, it would be possible, at least, to provide generic code to do > lookups within a single environment. We could conceal symbol table > indexing techniques behind this interface (linear search for > environments binding few identifiers, as compound statements often > are; hash tables for big environments; and so on), which would allow > us to change the representation without breaking the consumers > (... but maybe skip lists would be fine for all the above). > > We could then use that to write code for more specific cases: Completely agree! I like the look of this. The specific code to search a given level could call the general code "search me" and then recurse on its parents/outer wrappers/base classes/whatever. > - The code that looks up member names in a struct type (for example) > would call this generic code to search the immediate struct's > members, and then recurse on the struct's base classes, making the > appropriate adjustments (qualifying names, adjusting the base > address, and so on). > > - The code that searches compound statement scopes, from the innermost > enclosing statement out (eventually) to the global scope, would know > that inner declarations simply shadow outer declarations, rather > than introducing ambiguities (as inheritance does). If GDB were to > support nested functions, some steps outward might note that a > static link needs to be traversed. > > And so on. The generic code would only search one level; deeper > searches would be left to code that knows how they're supposed to > behave. > -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer