| RE: [cdt-core-dev] Open C++ Parser |
Thanks, Tom, these look like they are doing what we want. However, they are GPLed projects and my understanding is that GPL is problematic in the CPL world. Not sure why, and life would be easier if someone showed that this was not true. We could set up out-of-process links but I have doubts that would meet performance requirements, especially for the real-time users of the parser (e.g. code complete).
As for Java being a requirement, I guess not really. My feeling is that life will be easier if it is in Java since the clients that use the parser in real-time are in the Java world. However, if we find we can't get the performance to the point where the parser is unobtrusive, then we'll have to port to C++ using JNI to allow clients to get at parse info. My main concern there is the performance of JNI. I've seen some horrible results, especially when passing strings.
Doug Schaefer
Senior Staff Software Engineer
Rational - the software development company
Ottawa (Kanata), Ontario, Canada
-----Original Message-----
From: Tom Tromey [mailto:tromey@xxxxxxxxxx]
Sent: December 12, 2002 9:07 PM
To: cdt-core-dev@xxxxxxxxxxx
Subject: Re: [cdt-core-dev] Open C++ Parser
>>>>> "Doug" == Schaefer, Doug <dschaefer@xxxxxxxxxxxx> writes:
I have a few comments and questions about parsing.
Doug> We're having a lot of fun here porting the Open C++ parser to
Doug> Java for potential use in the CDT.
Is writing it in Java a requirement?
A long time ago, Red Hat (and before it Cygnus) had a product called
Source Navigator that included C and C++ parsers (and a bunch of other
ones). These live on in a sourceforge project:
http://sourceforge.net/projects/sourcenav/
Now, my recollection was that the C++ parser had big problems. But
this thread seems to indicate that really it is ok:
http://sourceforge.net/mailarchive/forum.php?thread_id=877927&forum_id=8966
Also see the "SourceBase" spin-off project:
http://sourcebase.sourceforge.net/
It may be worth looking into these to see if they are usable.
In S-N each parser was an independent program that wrote its results
to a database; S-N itself did queries in this database to get the
information it wanted. If the CDT did this then I think there
wouldn't be a GPL problem. (Or perhaps the licensing is changeable.
That could be looked into.)
I think it would make sense to at least investigate this option.
One benefit is that other projects appear to use this code, so
maintenance could be shared.
The S-N parsers, as a rule, were not precise. They didn't require
grammatically correct programs, but rather would generally recover
from errors and continue on. I believe the rationale for this was
two-fold. First, given the presence of the preprocessor, it was very
difficult to do a precise parse. Second, this meant that S-N could be
used on code that didn't compile -- this is an actual advantage. I
don't really have any more details than this, though I could try to
dig some up if anybody is interested.
Tom
_______________________________________________
cdt-core-dev mailing list
cdt-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-core-dev