Re: symbol lookup and overload resolution

Richard Kelly <[email protected]>
Newsgroups gmane.comp.documentation.synopsis
Organization Jet Propulsion Laboratory
Message-ID <[email protected]>
Stefan Seefeld wrote:
> 
> Now I'm cleaning up, refactoring, and enhancing the C++ parser with
> the goal to make the lower level APIs (parse tree, symbol lookup, 
> etc.) publicly usable, too.

Here's an example I ran into just today.  At a certain point, my 
prototype tool is analyzing class C and it needs to see if function f() 
is visible.  f() might be a member function in C, or it might be a free 
function in the scope containing C, or it might be a free function in 
the scope containing that scope, and so on.  (I know there are other 
possibilities, too, what with namespace using directives, Koenig lookup, 
and all.  However, I ignored those possibilities in my first attempt.)

There didn't seem to be a ready made symbol lookup function for me to 
use -- unless I overlooked it? -- so I wrote my own function to search 
all the scopes from class C outwards to the global namespace.  Once your 
symbol lookup API is publicly usable, will I just be able to call it and 
get back the function f() that's visible at that point, if any?  And if 
there are multiple functions named f(), will I get back the set of 
functions that would be candidates for overload resolution?  Either 
would suffice, I think, because the analysis I'm doing should make it 
easy to choose the right function from a set of functions.

> The first step into that direction was the creation of a new C++ 
> library that programs can link to directly, i.e. without having to 
> use a python frontend.

That sounds sweet.  My prototype tool is written in Python, and there's 
no particular reason now for me to worry about rewriting it in C++. 
However, I have noticed that almost all of its time is spent in the call 
to Cxx.Parser.process(), even for relatively small input files.  Once 
your C++ library is stable, should I expect a speedup in parsing?

> As I said, the first benefit will be that the parser can work 
> correctly in areas where it wasn't.

Definitely.  Which reminds me, with your latest updates to Synopsis, 
will it correctly parse all of the C++ language?  Templates, 
specializations, Koenig lookup, virtual inheritance, etc.?  We make 
pretty good use of the language here, and if possible I'd like to be 
able to tell my co-workers that the tool I'm building on top of Synopsis 
will handle any source code that they throw at it.

Also, are your latest updates ready for use now, or should I wait a 
while before downloading them?  Your 2005/01/29 snapshot is working 
great for me so far, but once you feel confident in your most recent 
work, I'd like to start using it.

>> That's exciting news.  By the way, I've already been able to build
>> a (prototype) code analysis/generation tool on top of Synopsis.
> 
> That sounds great ! Can you describe what you are doing and how ? 
> Once I understand what you want to do I may be able to suggest 
> alternative approaches with the new APIs.

Sure thing, but to keep this message from being too long, I'll describe 
the tool in my next message after this one.

Rick
-- 
Richard M Kelly                             [email protected]
[PGP  =>  D5 C3 CC D2 B7 D0 A9 B0  D5 90 B2 55 5A 80 23 B6  FC AB 67 B4]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.