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]