From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28703 invoked by alias); 17 Sep 2002 20:34:54 -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 28695 invoked from network); 17 Sep 2002 20:34:53 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 17 Sep 2002 20:34:53 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rPzZ-0004S4-00; Tue, 17 Sep 2002 16:34:45 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rP3W-0007xn-00; Tue, 17 Sep 2002 16:34:46 -0400 Date: Tue, 17 Sep 2002 13:34:00 -0000 From: Daniel Jacobowitz To: Daniel Berlin Cc: Andrew Cagney , David Carlton , gdb Subject: Re: struct environment Message-ID: <20020917203446.GA30594@nevyn.them.org> Mail-Followup-To: Daniel Berlin , Andrew Cagney , David Carlton , gdb References: <20020917180211.GA23552@nevyn.them.org> <0221994A-CA77-11D6-9548-000393575BCC@dberlin.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0221994A-CA77-11D6-9548-000393575BCC@dberlin.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00239.txt.bz2 On Tue, Sep 17, 2002 at 03:52:33PM -0400, Daniel Berlin wrote: > > On Tuesday, September 17, 2002, at 02:02 PM, Daniel Jacobowitz wrote: > > >On Tue, Sep 17, 2002 at 01:54:07PM -0400, Andrew Cagney wrote: > >>>Well, sort of. It won't be a DAG necessarily (I think that mutual > >>>>>"using" statements are legal in C++; I remember a GCC bug involving > >>>>>them was fixed not long ago), and it will be somewhat complicated > >>>>>figuring out which ones to look up (namespace links are different > >>>>>than > >>>>>block scope links). > >>> > >>>> > >>>>Don't forget that GDB doesn't need to model the language. Just the > >>>>namespace behavior at a given PC. The effect of "using" would be to > >>>>just grow a nametab in someway. > >>> > >>> > >>>This is legal C++: > >>> > >>>namespace D {} > >>> > >>>namespace C { > >>> using namespace D; > >>> int x, y; > >>>} > >>> > >>>namespace D { > >>> using namespace C; > >>> int x, z; > >>>} > >>> > >>>If using just grew a nametab we'd get into a great deal of trouble. > >> > >>Depends on how you grow it :-) Something like (assuming a real > >>language > >>:-): > >> D: > >> 0: x, z > >> 1: x, y (from C) > >> 2: ... > > > >How you intend to do this efficiently I don't know. Remember that C > >uses D in turn, and that things "using"'d into D will therefore be > >visible in C. > > These types of problems are exactly why i said a lot of thought needs > to be put into the design of the underlying structures, rather than > just copying what we have because we have it. > It's hard to call it "overengineered" if how to do lookups efficiently > with large numbers of names in namespaces hasn't been considered. > It's not really something you can bolt on later. > Hasn't this been proven by the fact that it hasn't been bolted on yet? Absolutely. But I've always thought that we'd still do it via searching a succession of blocks, with some sort of global structure for figuring out where to look; which means that at this point it's been designed far enough. I could be wrong :) -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer