From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13224 invoked by alias); 16 Apr 2002 19:08:05 -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 13051 invoked from network); 16 Apr 2002 19:08:00 -0000 Received: from unknown (HELO zwingli.cygnus.com) (208.245.165.35) by sources.redhat.com with SMTP; 16 Apr 2002 19:08:00 -0000 Received: by zwingli.cygnus.com (Postfix, from userid 442) id CB0EE5EA11; Tue, 16 Apr 2002 14:07:22 -0500 (EST) To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements References: <20020406044204.245E45EA11@zwingli.cygnus.com> <20020406013408.A4570@nevyn.them.org> <20020408214935.A14098@nevyn.them.org> <20020410150824.A22581@nevyn.them.org> <20020412195613.C11562@nevyn.them.org> From: Jim Blandy Date: Tue, 16 Apr 2002 12:08:00 -0000 In-Reply-To: <20020412195613.C11562@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/msg00271.txt.bz2 Daniel Jacobowitz writes: > > > Doing it for struct symbol would be a good idea, I think, but a better > > > approach would be: > > > - start the environments properly, using a new enum. > > > - Separate out those things which need to be "different kinds of > > > struct symbol", and keep the factoring at the environment level. > > > - Look up environment entries, not struct symbol's. That way we can > > > have a hope of keeping the right names attached to types, for > > > instance. > > > > By the last point here, are you suggesting that everyone hand around > > pointers to `struct environment_entry' objects, rather than pointers > > to `struct type', `struct field', etc.? That would lose some > > typechecking, and some clarity. If space is the concern, I think I'd > > rather see both the environment entry and the symbol/field/etc. have > > `name' fields, that perhaps point to the same string. > > There's a question of correctness, though. Suppose a type is imported > into a namespace - we don't want to create a new type for it, but we do > want to create a new name for it. I'm not sure what to do. You mean, imported via `using A::t', or via `using namespace A', where `A' binds `t' to a type? I guess I don't see the problem; could you be more explicit?