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

[Jim Blandy <jimb at redhat dot com>]

Jim Blandy <jimb@redhat.com> writes:
> As a half-baked idea, perhaps a `struct environment' object would have
> a list of other `struct environment' objects you should search, too,
> if you didn't find what you were looking for.  We could use this to
> search a compound statement's enclosing scopes to find bindings
> further out, find members inherited from base classes, and resolve C++
> `using' declarations.

>From the discussion, it's pretty clear that this idea is, indeed,
half-baked.  While the general idea of "stuff from over there is
visible here, too" does recur in the different contexts, there are so
many subtle differences in exactly what it means that I'm
uncomfortable having generic code try to handle it.  I have the
feeling that it would become populated with "if we're doing C++
inheritance, do this; but if we're stepping out to an enclosing
compound statement, do this; ..." garbage.  It's better to let the
context implement the right semantics itself.

However, it would be possible, at least, to provide generic code to do
lookups within a single environment.  We could conceal symbol table
indexing techniques behind this interface (linear search for
environments binding few identifiers, as compound statements often
are; hash tables for big environments; and so on), which would allow
us to change the representation without breaking the consumers
(... but maybe skip lists would be fine for all the above).

We could then use that to write code for more specific cases:

- The code that looks up member names in a struct type (for example)
  would call this generic code to search the immediate struct's
  members, and then recurse on the struct's base classes, making the
  appropriate adjustments (qualifying names, adjusting the base
  address, and so on).

- The code that searches compound statement scopes, from the innermost
  enclosing statement out (eventually) to the global scope, would know
  that inner declarations simply shadow outer declarations, rather
  than introducing ambiguities (as inheritance does).  If GDB were to
  support nested functions, some steps outward might note that a
  static link needs to be traversed.

And so on.  The generic code would only search one level; deeper
searches would be left to code that knows how they're supposed to
behave.