I don’t think that this
functionality should be added to CDT at this time. I’ll explain
why, but first, let me digress…
This is simply my opinion and you can
attach whatever weight that you want to it. I’m not trying to upset
anyone, but I AM trying to change the priorities of the team.
I think that CDT currently has enough “code-assist”
functionality. Sure, more is better, but adding more need not be a
In my personal opinion, there are 3
important issues with CDT that would keep me from recommending that Intel C++
customers use it (This is not to suggest that I ultimately make that decision…).
- Lack of complete functionality
in the build system: This has been discussed a lot, and I think that
this will be the easiest problem to fix. I’m not criticizing
the idea, the design, or the current implementation. It’s
simply that not enough resources have been applied to it.
- No support for different vendor
C/C++ language variants: My concern, directly related to Hoda’s
proposal, is that when parsing fails, all of the “code-assist”
functionality may be broken. Hoda, how certain are you that there
are not cases where your renaming functionality will do the wrong thing (without
the user being aware that it has done the wrong thing) when
- Scalability with large projects
with respect to code-assist functionality. I saw a few mails from
Thomas Fletcher in February that suggest to me that there are serious
problems. After my own review of the CDT design last Fall, I have
always been concerned that there is too much parsing and other reading of
source files (e.g. indexing) going on.
Numbers 2 and 3 look like hard problems
and need to be solved together.
In summary, with respect to Hoda’s
proposal, I don’t think that new “seed”s for additional
code-assist functionality should be added when the foundation to support it is
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Hoda Amer
Sent: Tuesday, March 09, 2004
Subject: [cdt-dev] Heads-up: A new
renaming UI tool
have been working on a new UI tool for renaming model elements. It relies on
search in finding all occurrences of a specific model element and changes the
found occurrences in the code to a new name. It could be invoked by a menu item
in the C/C++ Packages view.
have used the basic architecture of the JDT refactoring, but simplified it to a
great extent. In JDT, refactoring has many specific options depending on the
renamed element. It also has an undo manager and a sophisticated preview page.
Further, JDT has defined refactoring as an extension point such that
participants could change its behavior if they wish.
new tool does not have all of this. It just has a simple preview where the user
can choose to apply changes to a whole file or skip that specific file. It
totally depends on search, so its correctness is fairly high. It is not too
sophisticated and it does not have an undo manager; however, it can be viewed
as a seed that could be added to later to develop a solid refactoring tool.
am still testing the tool, but I am planning to submit it soon. I am interested
to know what everyone thinks about this.
Staff Software Engineer
Rational Software - IBM Software Group