Re: [cdt-dev] Updated CDT 2.0 Plan

["Treggiari, Leo" <leo.treggiari@xxxxxxxxx>]

My name is Leo Treggiari and I work in the Intel compiler group as the 
IDE Architect.  I have been seriously looking into Eclipse and CDT for
only a few weeks, but since CDT 2.0 planning is taking place now, I have
decided it is time to change from a "lurker" to a "commenter".

The majority of the CDT 2.0 commited work so far seems to be focused on
the user experience and new functionality.  I'd like to argue for a 
different focus on infrastructure and extensibility.

It is my opinion that the "core" of IDE functionality is the Edit, Build,
Debug cycle that programmers typically spend a majority of their time in.
It is of primary importance that the IDE make this as easy and efficient
as possible.  I haven't spent much time with the Debug functionality, but
between Edit and Build, the CDT developers seem to have concentrated on
editing functionality.

In the Build area, the "managed make" support in 1.2 looks like a major 
improvement over the "code-your-own make" support in 1.1.  It still
has a way to go, and I am glad to see "Managed Build enhancements" as a
committed task in the plan.  I also think that the "Tools integration 
extensibility" task that is currently proposed, but not committed, is an
integral part of managed make support.  I and people I work with have come
up with a set of suggestions for the managed make support that I will 
submit in a separate message.

In the Editing area, there is basic text editing functionality (looks good),
syntax coloring (looks good, except that is also will need to handle 
language variants), and then all of the functionality collectively
referred to as "code-assist".  The CDT goal of providing the same sort of
functionality as JDT looks good, but I'm concerned by the current parsing 
infrastructure that is in place to support it.  Here are two comments/
questions concerning the parsing infrastructure:

1.  There seems to be 3 (or 4) different models of the C/C++ program/code
    produced via parsing - C Model, Index, DOM, AST (are DOM and AST the 
    same or different?).  Why so many?  I realize that they currently 
    support different features, so I'm not looking for that explanantion.
    Why is there a duplication of information (e.g. concerning the classes
    in a source file) and effort (e.g. parsing)?

2.  "Parser extensibility" is a proposed but not committed task.  I suggest 
    it should have a higher priority than the "new functionality" tasks.
    It seems to me that if a parse fails, e.g., because the source code is
    using a non-standard extension, then none of the code-assist 
    functionality is going to work for the code in that source file.
    Is that correct?

Regards,

Leo Treggiari
Intel Corp., Nashua, NH