Re: [cdt-dev] Updated CDT 2.0 Plan

[Douglas Schaefer <dschaefe@xxxxxxxxxx>]

Thanks, Leo, this is great feedback and we'll make sure we can address 
your concerns.

We will be spending a lot of time on managed build and tools extensibility 
(including parser) for 2.0.  We're just now beginning our planning for 
this release so are a little hesitant to commit to some of the features 
until we understand what we can accomplish. 

My goal with managed build is to make sure we get a great automated build 
environment into the CDT so that ISVs would not need to create their own 
to workaround shortcomings.  This will make tools integration much more 
straightforward and as well as simplifying the user experience.  But, yes, 
we are really only at the start and any assistance you can offer will 
certainly help achieve this goal.

As for the models, there are actually three at the moment (no DOM yet). 
The C Model provides what you see in the outline view. The indexer simply 
maps certain information like declarations, references, to files which is 
used to speed up search.  The AST is actually temporary objects created by 
the parser to help pass information about the parse back to its clients. 
The main reason we have multiple models is that each has different 
requirements for size (e.g. we would easily run out of memory if we kept 
the AST around for a large number of files).  Some of it is historical. 
The C Model was there first and we didn't want to make too much change to 
get the AST up and running.  But having said that, I definitely want to 
avoid the proliferation that we see in the JDT.  When it is time to do the 
DOM, we will take a good look at cleaning this up a bit.

Look forward to hearing from you again,

Doug Schaefer, Senior Software Developer
IBM Rational Software, Ottawa, Ontario, Canada



"Treggiari, Leo" <leo.treggiari@xxxxxxxxx> 
Sent by: cdt-dev-admin@xxxxxxxxxxx
10/17/2003 02:04 PM
Please respond to
cdt-dev@xxxxxxxxxxx


To
<cdt-dev@xxxxxxxxxxx>
cc

Subject
Re: [cdt-dev] Updated CDT 2.0 Plan






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

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev