From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22712 invoked by alias); 6 Apr 2002 06:13:53 -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 22705 invoked from network); 6 Apr 2002 06:13:52 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 6 Apr 2002 06:13:52 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g366Dpm25134; Sat, 6 Apr 2002 01:13:51 -0500 Date: Fri, 05 Apr 2002 22:13:00 -0000 From: Daniel Berlin To: Michael Elizabeth Chastain cc: gdb@sources.redhat.com, , Subject: Re: C++ nested classes, namespaces, structs, and compound statements In-Reply-To: <200204060602.g3662gK28119@duracef.shout.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00077.txt.bz2 On Sat, 6 Apr 2002, Michael Elizabeth Chastain wrote: > I'll bite. > > > In summary, the data structure GDB needs to represent C++ structs > > (classes, unions, whatever) has a lot of similarities to the structure > > GDB needs to represent the local variables of a compound statement. > > Sounds reasonable to me. > > It also sounds dangerous. It's true that namespaces, structs, > and compound statements are all identifier binding contexts. > But if you start treating a struct as a type of compound statement > you could get into a maze of twisty forced meanings. You have to > reach down and create a new paradigm and then port both structs > and compound statements to it. > > Think about how much context information an identifier-binding-object > needs to do its job. I think it would be difficult to come up with a > universal context object that both structs and compound statements > can use. Each identifier-binding-object has its own specialized > context requirements. > > > - And what about ambiguous member names? > > The C++ language spec says: if class A inherits from both class B and > class C, and both B and C have a member "foo_", then an unqualified > reference to a.foo_ is illegal. The programmer has to say a::B.foo_ > or a::C.foo_. Not quite. Watch this cuteness, copied from the C++ draft standard: struct U { static int i; }; struct V : U { }; struct W : U { using U::i; }; struct X : V, W { void foo(); }; void X::foo() { i; //Finds U::i in two ways: as W::i and U::i // but no ambiguity because U::i is static } "A static member, a nested type or an enumerator defined in a base class T can unambiguously be found even if an object has more than one base class subobject of type T. Two base class subobjects share the non-static member subobjects of their common virtual base classes" In other words, it's not just statics. Observe: class V { public: int v; }; class A { public: int a; static int s; enum { e }; }; class B : public A, public virtual V {}; class C : public A, public virtual V {}; class D : public B, public C { }; void f(D* pd) { pd->v++; // ok: only one `v' (virtual) pd->s++; // ok: only one `s' (static) int i = pd->e; // ok: only one `e' (enumerator) pd->a++; // error, ambiguous: two `a's in `D' }