sourcenav and The Right Way to do it. (Re: c++ code completion status report)
Eray Ozkural (exa)
Fri Jan 4 10:47:00 GMT 2002
On Friday 04 January 2002 14:32, Andrea Aime wrote:
> Anyone of you gave a look at RedHat's Source Navigator?
> It has parsers for several languages, stores the parsed information
> in bynary files and provides some simple C api to access them...
> using these files the Source Navigator GUI provides a list of every
> function/class/method/file parsed and full cross referencing... it doesn't
> know about signals and slot, but I guess only some modification to
> the available parsers is needed... using the API you will get also an
> uniform way to deal with C, Fortran, Perl, Tcl, Python etc. etc.
> Source navigator is GPL'd and can be found on sources.redhat.com.
> Hope this helps
I maintain sourcenav for debian. I've also written a call graph generator
using the API. It's pretty slick because it uses Berkeley DB instead of a
slooow XML approach.
What it offers you is a nice efficient database that you can access in a
variety of ways. Please install sourcenav, see what it does, take a look at
the API docs and examples, and then let's discuss it.
For one thing, persistence means a file organization and AFAIK none of the
codes you've been talking about can give you true persistence. [*]
Sourcenav's parsers and database routines are fairly generic and can easily
be reused in gideon. [+] They also offer much richer functionality than what
we have in gideon.
Another thing: not all relations are best represented in an ASCII tree which
is DOM. I feel like repeating myself, on #kde and here, but: DOM (or XML)
isn't a subsitute for a mathematical model, or a proper data structure, or an
algorithm. Not all programming domains require TRANSMISSION of structured
(unfortunately here it is read: hierarchical, as in a tree) data (read:
untyped, dumb data) between INDEPENDENT applications and hardware. Here, we
have *one* application, that has to do *one* thing right, and we have access
to *all* the source code, and we know how to retrieve/store that data, how to
invoke parsers, etc. [!]
So a persistent class store indeed is the right way to go, but how
extensible/generic/persistent is it really? And should we really re-invent
I'm cc'ing to sourcenav list to see what sourcenav people's think of the
reusability of sourcenav code in another IDE.
[*] Umm, even the stock sourcenav code might not give that without tweaking!
In a really persistent system, you shouldn't have to reconstruct all objects
into memory upon initialization, etc. I don't know how far sourcenav really
goes, but it does have a "loading" phase when you open a project.
[+] And no, database does not mean a bloated SQL server.
[!] So, you will ask me, are trees useless? Of course they are useful, when
your algorithms will work with a tree. A tree that can hold arbitrary _data_
_structures_ (rather than expensive ASCII/Binary items) at nodes and leaves
of course, or a special tree like a binary tree or an AVL tree. When the data
is large, an out-of-core tree is also very very useful. I know how to make
one but it's beyond the scope of discussion ;) In this case however, a
relational model seems to be more appropriate than a hierarchical database.
Eray Ozkural (exa) <firstname.lastname@example.org>
Comp. Sci. Dept., Bilkent University, Ankara
GPG public key fingerprint: 360C 852F 88B0 A745 F31B EA0F 7C07 AE16 874D 539C
More information about the Sourcenav