From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7896 invoked by alias); 18 Sep 2002 04:51:49 -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 7889 invoked from network); 18 Sep 2002 04:51:48 -0000 Received: from unknown (HELO mail.cdt.org) (206.112.85.61) by sources.redhat.com with SMTP; 18 Sep 2002 04:51:48 -0000 Received: from www.dberlin.org (pool-138-88-148-121.esr.east.verizon.net [138.88.148.121]) by mail.cdt.org (Postfix) with ESMTP id 36C3B490054; Wed, 18 Sep 2002 00:29:17 -0400 (EDT) Received: from dberlin.org (unknown [192.168.0.252]) by www.dberlin.org (Postfix) with ESMTP id 6999B1810062; Wed, 18 Sep 2002 00:51:47 -0400 (EDT) Date: Tue, 17 Sep 2002 21:51:00 -0000 Subject: Re: struct environment Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Andrew Cagney , David Carlton , gdb To: Daniel Jacobowitz From: Daniel Berlin In-Reply-To: <20020917203446.GA30594@nevyn.them.org> Message-Id: <55FB82EE-CAC2-11D6-9548-000393575BCC@dberlin.org> Content-Transfer-Encoding: 7bit X-SW-Source: 2002-09/txt/msg00250.txt.bz2 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. :) --Dan