This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: C++ nested classes, namespaces, structs, and compound statements
- From: Petr Sorfa <petrs at caldera dot com>
- To: Jim Blandy <jimb at redhat 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: Tue, 09 Apr 2002 10:02:59 -0400
- Subject: Re: C++ nested classes, namespaces, structs, and compound statements
- Organization: Caldera
- References: <20020406044204.245E45EA11@zwingli.cygnus.com> <np7knhsra6.fsf@zwingli.cygnus.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.