This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ nested classes, namespaces, structs, and compound statements

Daniel Jacobowitz <> 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 said:

Per Bothner <> 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:

   namespace A
     int x;

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 A
      int x;

    int y;

    namespace B
      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
do this?

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]