From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9809 invoked by alias); 16 Apr 2002 21:01:19 -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 9799 invoked from network); 16 Apr 2002 21:01:16 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 16 Apr 2002 21:01:16 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16xa55-0000iS-00; Tue, 16 Apr 2002 17:01:39 -0400 Date: Tue, 16 Apr 2002 14:01:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: gdb@sources.redhat.com Subject: Re: C++ nested classes, namespaces, structs, and compound statements Message-ID: <20020416170139.A2371@nevyn.them.org> Mail-Followup-To: Jim Blandy , gdb@sources.redhat.com 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00272.txt.bz2 On Tue, Apr 16, 2002 at 02:07:22PM -0500, Jim Blandy wrote: > > 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? Well, neither of those exactly - in those cases the type is still named 't'. The only interesting problem with those examples is whether the type is still named A::t (as opposed to new_namespace::t) in that case; I'm not sure what C++ says about that. I was talking about this example from Daniel Berlin: #include using namespace bob = std; bob::string a; It doesn't seem to be the problem I thought it was, since it only happens to namespaces and not to namespace members like types. So this is not a real problem. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer