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

[Petr Sorfa <petrs at caldera dot com>]

Hi,

I've implemented FORTRAN95 MODULE support which is essentially
equivalent to namespaces (except you cannot have nested MODULEs.) I
treat it internally as a static class. For scoping issues I simply add
(in DWARF) the current local symbols to the MODULE to the local symbols
of the PROGRAM, CONTAINS, SUBROUTINE and FUNCTION scopes. A similar kind
of approach will allow nested C++ namespaces (flame bait comment.)

Petr
> 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.