From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32382 invoked by alias); 9 Apr 2002 13:55:16 -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 32375 invoked from network); 9 Apr 2002 13:55:14 -0000 Received: from unknown (HELO tetsuo.nj.caldera.com) (63.124.204.226) by sources.redhat.com with SMTP; 9 Apr 2002 13:55:14 -0000 Received: from caldera.com (localhost.localdomain [127.0.0.1]) by tetsuo.nj.caldera.com (8.11.6/8.11.6) with ESMTP id g39E32900908; Tue, 9 Apr 2002 10:03:02 -0400 Message-ID: <3CB2F493.7576E440@caldera.com> Date: Tue, 09 Apr 2002 06:55:00 -0000 From: Petr Sorfa Organization: Caldera X-Accept-Language: en MIME-Version: 1.0 To: Jim Blandy 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> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00127.txt.bz2 Hi, I've implemented FORTRAN95 MODULE support which is essentially equivalent to namespaces (except you cannot have nested MODULEs.) I treat it internally as a static class. For scoping issues I simply add (in DWARF) the current local symbols to the MODULE to the local symbols of the PROGRAM, CONTAINS, SUBROUTINE and FUNCTION scopes. A similar kind of approach will allow nested C++ namespaces (flame bait comment.) Petr > 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: > > - 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.