Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Berlin <dan@dberlin.org>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: gdb@sources.redhat.com, <jimb@redhat.com>, <bkoz@redhat.com>
Subject: Re: C++ nested classes, namespaces, structs, and compound statements
Date: Fri, 05 Apr 2002 22:13:00 -0000	[thread overview]
Message-ID: <Pine.LNX.4.44.0204060107490.24864-100000@dberlin.org> (raw)
In-Reply-To: <200204060602.g3662gK28119@duracef.shout.net>

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'
          }






  reply	other threads:[~2002-04-06  6:13 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-05 22:02 Michael Elizabeth Chastain
2002-04-05 22:13 ` Daniel Berlin [this message]
2002-04-05 22:30   ` Daniel Berlin
  -- strict thread matches above, loose matches on Subject: below --
2002-04-05 20:42 Jim Blandy
2002-04-05 22:05 ` Daniel Berlin
2002-04-05 22:34 ` Daniel Jacobowitz
2002-04-05 23:49   ` Daniel Berlin
2002-04-06  7:18     ` Dan Kegel
2002-04-06  9:26     ` Gianni Mariani
2002-04-06 11:57       ` Daniel Berlin
2002-04-08 17:24       ` Jim Blandy
2002-04-08 17:03   ` Jim Blandy
2002-04-08 18:59     ` Daniel Jacobowitz
2002-04-09 18:35       ` Jim Blandy
2002-04-09 20:56         ` Daniel Jacobowitz
2002-04-12 15:08           ` Jim Blandy
2002-04-12 16:32             ` Daniel Jacobowitz
2002-04-08 17:19   ` Jim Blandy
2002-04-08 18:49     ` Daniel Jacobowitz
2002-04-10 10:31       ` Jim Blandy
2002-04-10 12:08         ` Daniel Jacobowitz
2002-04-12 13:58           ` Jim Blandy
2002-04-12 16:56             ` Daniel Jacobowitz
2002-04-16 12:08               ` Jim Blandy
2002-04-16 14:01                 ` Daniel Jacobowitz
2002-04-16 14:52               ` Jim Blandy
2002-04-16 14:58                 ` Daniel Jacobowitz
2002-04-06  6:31 ` Andrew Cagney
2002-04-06  7:58   ` Daniel Berlin
2002-04-08  0:59   ` Joel Brobecker
2002-04-06  8:49 ` Per Bothner
2002-04-08 16:29 ` Jim Blandy
2002-04-08 16:48   ` Daniel Jacobowitz
2002-04-09  6:55   ` Petr Sorfa
2002-04-10 10:34     ` Jim Blandy
2002-04-10 12:31       ` Daniel Berlin
2002-04-10 12:53         ` Petr Sorfa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.44.0204060107490.24864-100000@dberlin.org \
    --to=dan@dberlin.org \
    --cc=bkoz@redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=jimb@redhat.com \
    --cc=mec@shout.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox