This is the mail archive of the
mailing list for the GDB project.
Re: C++ nested classes, namespaces, structs, and compound statements
- From: Jim Blandy <jimb at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com, Benjamin Kosnik <bkoz at redhat dot com>,Daniel Berlin <dan at dberlin dot org>
- Date: 08 Apr 2002 19:02:58 -0500
- Subject: Re: C++ nested classes, namespaces, structs, and compound statements
- References: <20020406044204.245E45EA11@zwingli.cygnus.com><20020406013408.A4570@nevyn.them.org>
Daniel Jacobowitz <firstname.lastname@example.org> writes:
> GDB already does a great deal of this by the very simple method of
> using fully qualified names. It's served us remarkably well, although
> of course we're hitting its limits now. But let's not be too quick to
> discard that approach, for the present at least.
Oh dear. I think that's exactly what I'm proposing we replace. As
Per Bothner <email@example.com> writes:
> Nothing much to add, except that namespace support is even
> more critical for Java, in which *all* code uses namespaces
> (aka "packages"). We kludge around it, by treating a compound
> name like 'java.lang.Object' as a single name, but this doesn't
> work all that well, especially with mixed Java/C++ code.
It just seems natural to represent something like:
as a binding in the top-level environment for the symbol A, saying
it's a namespace. That binding would have another environment object
representing the contents of A; there we'd find a binding for 'x',
saying it's a global variable of type `int'. Presented with something
like `A::x', we'd first look up `A', check that it is a namespace or
struct or something else that can qualify names, and then look in A's
environment for `x'.
Think about how namespace aliases need to work:
namespace A2 = A;
foo (int y)
namespace B2 = B;
return B2::A2::x + y;
The `namespace A2 = A' declaration in `namespace B' really should
create a new entry in B's environment which binds A2 to the same
namespace object A is bound to. The `namespace B2 = B' declaration
should modify foo's local variable environment to bind B2 to the same
namespace object B is bound to.
In that situation, we can look up things like `B2::A2::x' in a
straightforward way: look up B2, look up A2 there, and look up x
there. With a symbol table full of fully qualified names, how do we
Can you talk more about why we shouldn't evolve away from placing
fully qualified names in the symbol table directly, and towards
representing them more explicitly?