On Tue, 29 Apr 2003 11:10:05 -0400, Andrew Cagney <ac131313@redhat.com> said:
On Fri, 25 Apr 2003 11:31:35 -0400, Andrew Cagney <ac131313@redhat.com> said:
Ok, humor me ...
http://sources.redhat.com/ml/gdb/2003-04/msg00017.html why even
build these data structures during symbol reading? It takes time
and space, yet is probably never used. Why not on-demand build this
dictionary specialized for the block?
That sounds great to me if we can get it to work. It's certainly
another reason to try to get the symbol lookup stuff abstracted behind
an opaque interface: it makes lazy loading of data a lot easier.
But which interface?
A block has a language, and [I think] it's the language that, in the
end decides that block's name->symbol lookup strategy. The language
can, on demand, build a dictionary for its block.
Currently, all uses of symbols in blocks either iterate over all
symbols or else are looking for symbols with a given natural name. As
you say, because of the features of certain languages, sometimes you
need to refine the search further beyond that, but that's a good first
cut. So having iterators dict_iterator_{first,next} and
dict_iter_name_{first,next} is a good first step: it unifies all the
existing mechanisms for symbol lookup, but doesn't commit to any sort
of implementation mechanism. It certainly would allow for
constructing the actual data structures on demand: for example, we
could add an implementation that doesn't actually build the data
structures storing the symbols until the first time that an iterator
is called.
I'm certainly willing to believe that the interface might change in
the future; but separating the interface from the implementation is a
good first step no matter what.
I kind of get the impression that I'm missing your point somehow and
that we're talking past each other. I'll post a concrete patch soon
(Wednesday, maybe? It's done on my laptop, but I don't have my laptop
with me), and hopefully that will clarify matters.