[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: probably the best C++ parser...
From:       Alexander Neundorf <neundorf () kde ! org>
Date:       2005-07-04 18:59:06
Message-ID: 200507042059.06518.neundorf () kde ! org
[Download RAW message or body]

Hi,

On Monday 04 July 2005 12:11, Andrew Sutton wrote:
> i figured i'd weigh in since this is interesting to me...
>
> > IMO, the optimal solution would be to use gcc parser running in
> > background. So, as you type, the parser will consume the tokens you've
> > typed, and provide exact information about type/members and so on.
>
> last time i checked, gccxml sucks as a "reverse/reengineering parser". it
> generates too much data to be even remotely efficient. unless the authors
> have changed how the program defines "translation unit", it's still
> performing regular c preprocessing (which is what really causes the bloat).

Yes, it "compiles" the file as gcc usually does, and produces xml output.

> > Another C++ parser I know about is Synopsis
> > (http://synopsis.sourceforge.net/), which is reported to even parse
> > Boost.
> >
> > At this point, I'm not quite sure if hacking gcc or improving Synopsis is
> > the best way to go.
>
> synopsis is certainly an option. you should also look at srcml
> (http://www.sdml.info/projects/srcml).
>
> the problem with all of these is that they're non-incremental. you run
> them. they generate data. you change the code and then you have to
> completely re-run the program and regenerate the data.

Yes, that's true. It takes some time. Maybe I'm too pessimistic, but for me 
the code completion/navigation/parsing in kdevelop doesn't work really good 
Completion sometimes works, usually it doesn't, go to defintion/declaration 
doesn't work reliably, especially with files outside the project, realtime 
syntax parsing doesn't work reliable. So I thought using a mature parser 
might be an improvement about the current situation, where we have to 
implement the parser ourselves (i.e. Roberto).
An unreliable features is as good as if it wasn't there at all. If it doesn't 
always work, the user (at least I) will never use it (because it will 
probably fail and then he has to use the alternative approach anyway).

> i think what you'd really want in an ide is an incremental, interactive
> parser. 

What I really want is a correct, reliable parser which produces correct 
results.
Ideally also incremental and interactive, yes. 

Bye
Alex
-- 
Work: alexander.neundorf@jenoptik.com - http://www.jenoptik-los.de
Home: neundorf@kde.org                - http://www.kde.org
      alex@neundorf.net               - http://www.neundorf.net

_______________________________________________
KDevelop-devel mailing list
KDevelop-devel@barney.cs.uni-potsdam.de
http://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]