From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19628 invoked by alias); 18 Sep 2002 14:26:43 -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 19554 invoked from network); 18 Sep 2002 14:26:42 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 18 Sep 2002 14:26:42 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17rgih-0005mb-00; Wed, 18 Sep 2002 10:26:27 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17rfmg-0006bd-00; Wed, 18 Sep 2002 10:26:30 -0400 Date: Wed, 18 Sep 2002 07:26:00 -0000 From: Daniel Jacobowitz To: Daniel Berlin Cc: Andrew Cagney , David Carlton , gdb Subject: Re: struct environment Message-ID: <20020918142630.GA24803@nevyn.them.org> Mail-Followup-To: Daniel Berlin , Andrew Cagney , David Carlton , gdb References: <20020917203446.GA30594@nevyn.them.org> <55FB82EE-CAC2-11D6-9548-000393575BCC@dberlin.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55FB82EE-CAC2-11D6-9548-000393575BCC@dberlin.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-09/txt/msg00256.txt.bz2 On Wed, Sep 18, 2002 at 12:51:46AM -0400, Daniel Berlin wrote: > > On Tuesday, September 17, 2002, at 04:34 PM, Daniel Jacobowitz wrote: > > >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 :) > > This might be the case. > I'm just trying to make sure it *has* been considered. > I'm not saying it actually requires any changes to the proposed way of > doing things. > > In legal terms, i'm raising the objection to preserve it for a possible > later appeal. > :) Well then - it has been considered. I'm not sure it's been considered _enough_, but only time is going to answer that. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer