This is the mail archive of the gdb@sources.redhat.com 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: struct environment


On Tue, 17 Sep 2002 09:40:57 -0400, Daniel Jacobowitz <drow@mvista.com> said:
> On Tue, Sep 17, 2002 at 03:47:36AM -0400, Andrew Cagney wrote:

>> - Am I correct to think that the objective is to create a directed
>> acyclic graph of nametabs and have lookups search through each in turn.

> Well, sort of.  It won't be a DAG necessarily (I think that mutual
> "using" statements are legal in C++; I remember a GCC bug involving
> them was fixed not long ago), and it will be somewhat complicated
> figuring out which ones to look up (namespace links are different
> than block scope links).

That last parenthetical comment is important.  (And I hope it will
only be 'somewhat' complicated...)

If you have a C++ file like this:

using namespace A;

int foo()
{
  // body of function
}

then 'foo' gets added to the global environment, but the 'using
namespace A' doesn't affect the global enviroment, just this
particular file.  (E.g. it modifies the search rules in the body of
the function.)  So 'using' statements only modify symbol lookups, they
don't modify symbol definitions.  In contrast, the curly braces around
the body of the function modify two things: they modify symbol
definitions (since new variables defined in the body _aren't_ visible
in the global environment), and they also modify symbol definitions.

So you have to be able to deal with language constructs that only
modify where symbols are looked up as well as language constructs that
modify where symbols are looked up _and_ where symbols are added; and,
in the former case, you have to make sure that you only modify where
symbols are looked up in one particular chunk of the code, not in the
entire enviroment where symbols are currently being added.  (And,
incidentally, 'using' isn't the only way that name lookup can get
modified in this sort of way.)

Because of this, I don't think it's very useful to conflate these two
sorts of relationships between environments and just talk about a DAG.
There should be a tree reflecting the block structure (which we
already have, of course); and there should be some other data
structure reflecting additional symbol lookup rules.  And I'm not sure
yet exactly what that other data structure should look like, or how it
should interact with the block structure tree.  Or, for that matter,
whether either kind of data should stay within struct block or move
within struct dictionary.  (I'm leaving everything in the former until
I'm sure it should move.)

Obviously I need to read the relevant parts of the C++ standard before
working on namespaces proper.  For what it's worth, I think the
relevant buzzword is 'Koenig lookup', but I could be wrong.  And I
just hope and pray that other languages with complicated name lookup
rules use the same mechanisms as C++...

David Carlton
carlton@math.stanford.edu


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