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