The future of gideon

Ivan Hawkes blackhawk at ivanhawkes.com
Wed May 29 09:52:03 UTC 2002


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 28 May 2002 3:14 pm, Philippe FREMY wrote:
> > -- Code Completion --
> >
> > Unfortunately, C++ is very difficult to parse. I did a bit
> > of searching on the subject and found some useful info like:
> >
> > http://www.tardis.ed.ac.uk/~adb/compilers/cplusplus.html
> >
> > And a post from Eray to the sourcenav mailing list, with
> > promising responses:
> >
> > http://sources.redhat.com/ml/sourcenav/2002-q1/msg00023.html
> >
> > Eray, what is the status of making an API out of sourcenav?
> > Robe, and others working/thinking about such things: what are your
>
> thoughts?
>
> > Personally, I think we must find or join forces with others who have
> > working C++ parsers or who follow similar goals. Sourcenav looks
> > promising

I'd have to agree. Writing yet another c++ code parser to integrate code 
completion seems to fly in the face of object oriented design and code 
re-use. For me the big question is whether SourceNav can do incremental 
updates at a procedural level. This is the feature we will need to make 
cohesive code completion. There's not much use having code completion that 
can't pick up on the variables you just defined in the line above a moment 
ago.

> in this respect.
>
> Indeed. Since I have been looking around for a C++ parser for my
> refactoring project, I can share my results with you:
>
> Sourcenav offers two possibilities:
> 1. use their parser to generate their database and then use the database
> 2. use their code to generate our own C++ parser.
>
> The first approach guarantees a stable long tested database of symbol with
> optimal reconstructing. However, it will be harder to modify if you don't
> find what you are looking for inside the database. For refactoring for
> example, I need the variable declarations and a more precise usage info of
> everything. But for code completion and class-browsing, you have more than
> you need.

Multiple languages are covered...nice! We could just add parsers for the 
various other languages that people are interested in, without having to 
re-invent the wheel for the more common ones.

> The second approach is possible because all the sourcenavigator parsers
> calls functions like sn_insert_symbol and sn_insert_xref to update the
> symbol database. Sourcenav's implementation calls the database but if you
> provide these functions, you can do whatever you want in the calls.
> See http://sourcenav.sourceforge.net/online-docs/progref/addparsers.html
> for slightly more info.
>
> Sourcenavigator's doc provides very little info on how to run the parser
> itself.
>
> The other interesting projects I found:
> http://www.csg.is.titech.ac.jp/~chiba/openc++.html
> http://www.site.uottawa.ca:4333/dmm/index.html
> http://www.cs.utoronto.ca/~simsuz/cascon2001/workshop.html
> http://www.empathy.com/pccts/download.html
> http://www.gccxml.org/HTML/Index.html
>
> Most of them are unappropriate for full C++ parsing like I need, but
> perfectly ok for completion and class-browsing.
>
> 	Philippe
> ###########################################
>
> This message has been scanned by F-Secure Anti-Virus for Microsoft
> Exchange. For more information, connect to http://www.F-Secure.com/
>
>
> _______________________________________________
> Kdevelop-devel mailing list
> Kdevelop-devel at barney.cs.uni-potsdam.de
> http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel

- -- 
Ciao,	
     Ivan Hawkes <BlackHawk>

    "Life, don't talk to me about life...", Marvin the Paranoid Android
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBPPSHeGKLnTKzOO4NEQKlCQCgvTxdLlfDMesrAnbzNsWB1afosNQAoNTR
ntMaCyAYZ1nNKgLWXDxiqTWz
=EQPt
-----END PGP SIGNATURE-----





More information about the KDevelop-devel mailing list