From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 666 invoked by alias); 8 Apr 2002 23:29:39 -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 651 invoked from network); 8 Apr 2002 23:29:38 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 8 Apr 2002 23:29:38 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 58BC15EA11; Mon, 8 Apr 2002 18:29:37 -0500 (EST) To: gdb@sources.redhat.com Cc: Benjamin Kosnik , Daniel Berlin Subject: Re: C++ nested classes, namespaces, structs, and compound statements References: <20020406044204.245E45EA11@zwingli.cygnus.com> From: Jim Blandy Date: Mon, 08 Apr 2002 16:29:00 -0000 In-Reply-To: <20020406044204.245E45EA11@zwingli.cygnus.com> 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/msg00103.txt.bz2 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.