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
On Mon, Apr 08, 2002 at 06:29:37PM -0500, Jim Blandy wrote:
>
> 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:
Completely agree! I like the look of this. The specific code to
search a given level could call the general code "search me" and then
recurse on its parents/outer wrappers/base classes/whatever.
> - 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.
>
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer