From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18459 invoked by alias); 9 Apr 2002 00:03:01 -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 18450 invoked from network); 9 Apr 2002 00:03:00 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 9 Apr 2002 00:03:00 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id 09AC75EA11; Mon, 8 Apr 2002 19:02:58 -0500 (EST) To: Daniel Jacobowitz 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> <20020406013408.A4570@nevyn.them.org> From: Jim Blandy Date: Mon, 08 Apr 2002 17:03:00 -0000 In-Reply-To: <20020406013408.A4570@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/msg00105.txt.bz2 Daniel Jacobowitz writes: > GDB already does a great deal of this by the very simple method of > using fully qualified names. It's served us remarkably well, although > of course we're hitting its limits now. But let's not be too quick to > discard that approach, for the present at least. Oh dear. I think that's exactly what I'm proposing we replace. As Per said: Per Bothner writes: > Nothing much to add, except that namespace support is even > more critical for Java, in which *all* code uses namespaces > (aka "packages"). We kludge around it, by treating a compound > name like 'java.lang.Object' as a single name, but this doesn't > work all that well, especially with mixed Java/C++ code. It just seems natural to represent something like: namespace A { int x; }; as a binding in the top-level environment for the symbol A, saying it's a namespace. That binding would have another environment object representing the contents of A; there we'd find a binding for 'x', saying it's a global variable of type `int'. Presented with something like `A::x', we'd first look up `A', check that it is a namespace or struct or something else that can qualify names, and then look in A's environment for `x'. Think about how namespace aliases need to work: namespace A { int x; }; int y; namespace B { namespace A2 = A; } int foo (int y) { namespace B2 = B; return B2::A2::x + y; } The `namespace A2 = A' declaration in `namespace B' really should create a new entry in B's environment which binds A2 to the same namespace object A is bound to. The `namespace B2 = B' declaration should modify foo's local variable environment to bind B2 to the same namespace object B is bound to. In that situation, we can look up things like `B2::A2::x' in a straightforward way: look up B2, look up A2 there, and look up x there. With a symbol table full of fully qualified names, how do we do this? Can you talk more about why we shouldn't evolve away from placing fully qualified names in the symbol table directly, and towards representing them more explicitly?