Re: C/C++ codes searching/browsing

["Artem Khodush" <kaa at comail dot ru>]

Brad King <brad.king@kitware.com> wrote:

> A few weeks ago I noticed a message on this list asking about a tool to do
> C++ code searching/browsing.  While there were a few third-party tools
> listed in a response to this message, there doesn't seem to be a general
> purpose solution.

Well, I think that the best (open-source) approximation to a "general purpose 
solution for code searching/browsing" currently is source navigator
(http://sources.redhat.com/sourcenav/), released just a few weeks ago.

> I am working on an addition to GCC's C++ front-end that adds a compiler
> flag (-fxml) which triggers special processing at the end of a translation
> unit.  Eventually, this processor will walk the entire translation unit,
> starting at the global namespace (or perhaps a specified scope name?),
> and write out an XML file describing the contents of each namespace/class
> scope.  These files could then be read by any tool for any purpose,
> freeing these tools of the nasty task of parsing C++.  Source
> file/line number element attributes could be added to allow these tools
> to go back to the source and extract comments corresponding to each
> definition.

Speaking of browsing code, parsing C++ is not the hardest thing, especially
when you have g++ source code with wonderfully documented tree structure.
Ideally, you need cross-referencing information for all source files 
which went to the particular executable image, collected in one place. 
So that you can go directly from a call to a function to its definition in another 
file. And ideally, the browsing tool should not ask you 
"which of a set of overloaded definitions of foo would you like to go to", 
because compiler already did overload resolution for every call, and that 
information should be recorded in xref database. 

I think the best way to handle this is to create new gcc front-end, which
does cross-reference generation instead of compiling, and merges xref
info for different source files instead of linking. That way, you just
"make CC=new-front-end" for your project, and have relevant xref databases
built for all your executable images, with all linkage correctly resolved.
And I think that XML is not the best storage format for xref information. 
First, you need fast lookup during code browsing. Second, there might be 
need to update xref database incrementally for this tool to be usable for large 
projects. So some kind of "real" database may be needed for storage instead 
of XML files (this is the approach taken in the source-navigator).

Separation of this feature into new front-end will simplify (i hope) integration 
into the gcc distribution and maintainance. Sure, just adding new switch 
to gcc is much easier, but I suspect that the amount of code implementing 
this functionality will eventually grow to some unpleasant size. 

> I would like to know if this is something that could be added to GCC
> permanently, and thus be included in the distribution and maintained
> as GCC is updated.  Obviously we would have to agree on a DTD for the
> XML output.  The example below demonstrates an approach I've been thinking
> about.  It uses a minimal amount of XML's constructs, but something more
> advanced could be designed if it is appropriate.
> 
> I would appreciate any comments or suggestions on this, especially about
> the format of the XML output.  Also, is anyone else working on such a
> project, even if using a different output format?

I was thinking of implementing a new parser for the source-navigator, based
on gcc (specifically, on g++).

The XML output as it was, i think was unsutable for browsing. For each entity
referenced in a function body, you need to record exact position of reference in 
the source code, and provide a direct link (not just a name) to its declaration
(and possibly definition). Also, in real life, you should take into account 
macros (but that's whole another story).

Best regards,
Artem.