Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
CDT/Archive/survey/2010
Contents
Are you a CDT user or developer (CDT or CDT-based product)?
- User 47 (71%)
- Developer 19 (29%)
On which platform do you use CDT the most?
- Windows 19 (29%)
- Linux 39 (59%)
- Mac OS X 5 (8%)
- Other 3 (5%)
What would you like to be the focus of the next CDT major release (8.0) ?
- Improvements to the UI and usability 17 (26%)
- Improvements to the user documentation 11 (17%)
- Integration with other build systems 11 (17%)
- Integration with other compilers 14 (21%)
- Integration with other debuggers 12 (18%)
- More Refactorings and Source generation 25 (38%)
- More debugging features 18 (27%)
- Improvements to the build system 16 (24%
- Improvements to the editor and source navigation 25 (38%)
- More code analysis (optional in 7.0) 20 (30%)
- Better APIs for CDT developers 12 (18%)
- Better documentation in CDT code 15 (23%)
- Better stability 11 (17%)
- Better scalability and performance 28 (42%)
- Other 9 (14%)
People may select more than one checkbox, so percentages may add up to more than 100%.
Detailed Responses
Q1: Developer
Q2: Mac OS X
Q3: More Refactorings and Source generation, Integration with other compilers, Integration with other debuggers
Make working with C/C++ as easy and assisted as working with JDT/Java. Clang, llvm/lldb
Q1: User
Q2: Mac OS X
Q3: Improvements to the editor and source navigation
I'm using CDT mostly as editor/navigation tool. So I'm expecting imrovements in these area for large projects (faster multithreaded indexer, better parsing of templates, preprocessor defs, etc).
Also I'm interesting in general performance improvements for large projects (optional refresh after build, etc, faster refactoring, etc)
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, More Refactorings and Source generation, Improvements to the editor and source navigation, Better stability, Better scalability and performance
Performance: When big file (~7k lines) is being opened, it takes sometimes ~20 seconds till overview is being available (the first time) after that it takes additional ~20 seconds (the first time) till some navigation results are available. It is not really clear why at the beginning while outline is not available it is not possible to do any navigation actions.
Q1: User
Q2: Linux
Q3: More Refactorings and Source generation, Better scalability and performance
More Refactorings and Source generation: I need as complete as jdt Better scalability and performance: It is very slow for big projects specially the indexer.
Q1: User
Q2: Windows
Q3: Integration with other build systems, Integration with other compilers, Integration with other debuggers, More Refactorings and Source generation, More debugging features
1. Support for MSVC toolchain, including debugger. 2. Integration with CMake, wizard for importing CMake-based project. 3. More stable refactorings: only rename is usable now, other have problems with source code formating and often generate incorrect code. 4. Visualization of STL containers and iterators in debugger, as well as Qt types.
Q1: Developer
Q2: Linux
Q3: Improvements to the UI and usability, Improvements to the user documentation, Integration with other build systems, More Refactorings and Source generation, Improvements to the build system, More code analysis (optional in 7.0), Better scalability and performance
- Autotools integration
- scalability and performance are very important
- refactoring will bring new users
- getting started guides and other documentation (screencasts!) are very much in need
Q1: Developer
Q2: Windows
Q3: More debugging features, Better APIs for CDT developers, Better documentation in CDT code
Multi core debug for embedded systems. Better support for profiling applications.
Q1: Developer
Q2: Windows
Q3: Improvements to the editor and source navigation, Better APIs for CDT developers, Better documentation in CDT code, Better stability
Source navigation need to be improved . Code documentation need to be improved
Q1: User
Q2: Windows
Q3: Improvements to the UI and usability, More code analysis (optional in 7.0), Better APIs for CDT developers, Better documentation in CDT code
Within preferences one gets lost with all the categories and the hundreds of options that you can change. Regarding usability I belive the secondary click over the editor is really huge. For new users it is not trivial to find how to do something. Code analysys is a very important feature and that will help people if they don't have a static analysis tool (Codan) or if they do integrating it to the development environment. As someone writing static analysis checkers it was not trivial to find how to start and writing some value added checkers. You can always ask to the developers list but there is no good documentation on CDT architecture, components, etc.
On the other hand I have found many places in the CDT where the routines say nothing about what they do and their purpose. When there is no good documentation around for CDT developers and the code does not say much it is really hard to figure it out.
Q1: User
Q2: Linux
Q3: Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better stability, Better scalability and performance
a
Q1: Developer
Q2: Windows
Q3: Improvements to the UI and usability, More Refactorings and Source generation, Improvements to the editor and source navigation, More code analysis (optional in 7.0)
The list on http://wiki.eclipse.org/C_editor_enhancements describes what I'd like to see in CDT
Q1: Developer
Q2: Widows primarily but also Linux (and maybe Solaris)
Q3: Better APIs for CDT developers, Better documentation in CDT code
We are in the early stages of integrating our testing tool with CDT and need accesss to the Type tree, etc. Learning how to get what we need has been a little difficult.
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, More Refactorings and Source generation, More debugging features, Improvements to the build system
multi-core debug
Q1: Developer
Q2: Linux
Q3: Improvements to the user documentation, More debugging features
Multi-core debugging
Q1: User
Q2: Linux
Q3: Objective-C support
Please add Objective-C support. I use Eclipse for all my regular work based C/C++ projects - but i'm starting to use Objective-C more and more. Thanks
Q1: Developer
Q2: Windows
Q3: Integration with other compilers, More debugging features, Improvements to the build system, Better APIs for CDT developers, Better documentation in CDT code
A more flexible Managed Build system.
Q1: Developer
Q2: Linux
Q3: Integration with other build systems, Integration with other compilers, Integration with other debuggers, More debugging features, More code analysis (optional in 7.0), Better APIs for CDT developers
I have recently created an CDT plug-in to allow me to use scons without managed build.
At the moment I am attempting to create SDK's for cross compiling applications for deployment onto embedded devices. I would like these SDK's (toolchains + libraries + headers needed to compile C/C++ code for the target) to be listed as optional toolchains for things such as autotools project, makefile, projects, scons projects, etc. But this is proving rather difficult to do at the moment.
The Remote Debugging options also could use some work.
We also are using flexilent and I would like to see that integrated with CODAN
Q1: Developer
Q2: Linux
Q3: Improvements to the build system, Better documentation in CDT code, Better scalability and performance
The system for passing files/directories between projects is restictive and can't be extended by a contribution. Whilst CDT can support all the common types (which are basically option types) for a standard c compiler toolchain, a build system should ideally be more flexible (i.e. generic like make). This would support post processing tools in a more formal manner than just a post-build step amongst other things. Workspace level options are another feature that may ease usability of the build system such that related projects (possibly using dependencies) could optionally synchronise tool options. Whilst this feature potentially does not exist in many GUI build systems it should not be too hard to support and would have value if a build has many small static libraries linked together and each should be built with the same compiler options. Stability of the CDT internal builder and accurate rebuild would be very desirable. Swapping between internal and make based build systems gives the best of both worlds where an automated build may want to use make to build a system but in eclipse the internal builder is quicker (with fewer dependencies).
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, Integration with other debuggers, Improvements to the editor and source navigation
Would love an MSVC debugger integration. A bit more love in the CMake area (yes I know there is a generator, but it would be nice to just have eclipse import my CMakeLists and point to a build directory...) A bit of UI work to make it more like the JDT would be nice (rename refactoring pops up a dialog in CDT where JDT does it ""in-line"") CDT needs to do my homework for me!
Q1: User
Q2: Windows
Q3: Improvements to the user documentation, More debugging features, More code analysis (optional in 7.0), Profiler support
Gprof / Gcov integration would be nice.
Q1: User
Q2: Windows
Q3: More Refactorings and Source generation, Improvements to the editor and source navigation, Better scalability and performance
I work with largish data files (40k lines or so) that get #included into C code, and as far as I know they either end up un-indexed or they kill system performance.
Q1: User
Q2: Linux
Q3: More Refactorings and Source generation, More code analysis (optional in 7.0), Better scalability and performance, Better unit test integration (Google C++ Test Framework)
Better unit test integration (Google C++ Test Framework).
Pretty printing support would be great too.
Q1: User
Q2: Linux
Q3: Improvements to the editor and source navigation, Better stability, Better scalability and performance
CDT should be able to handle large source trees. For example, the Linux kernel tree. I have to say, CDT 7 is very good so far on reasonably large trees, giving Eclipse at least 1GB of memory. Haven't yet had the courage to fire it at the whole Linux kernel tree though.
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, More debugging features, Better scalability and performance
I work in an organization that has recently switched to Eclipse as the primary IDE for developing embedded software for a line of digital audio processing devices. Eclipse's extensibility is impressive, however we encounter build and performance problems due to our project structure, which I would think is not uncommon:
We have a code database organized into several ""components"" in Subversion. What we would normally call a ""project"" corresponds to a main.cpp and executable that will run in a particular device. Different product's project will likely share components with other projects. Also there are separate unit test subprojects that live underneath each component, each of which may have their own main.cpp and executable. Each atomic project (not in the eclipse sense) has its own makefile and can be built from the command line using GNU make.
So we don't have lots of duplicate components in separate projects (because the more files you have in eclipse workspace, the longer operations like refresh and index take), we have a monolithic subversion metaproject that pulls in the superset of the components and main project folders that we have. The root of this metaproject becomes the root of the eclipse project, and the eclipse and CDT project files live at that root.
So there is a lot of source code in the eclipse project and there are several ""buildables"" in a single eclipse project. Eclipse provides ""make targets"" which can be used to build each one, however this support is fairly inaccessible. It would be useful to be able to keyboard map the invocation of a specific make target. With a lot of make targets it is confusing to have to navigate the Make Targets View and double click on something instead of a keyboard shortcut.
The general performance of eclipse's indexing and refreshing is cumbersome, and there should be more customization in terms of bypassing certain operations, namely refreshing a project after a build (this adds lots of time to the build procedure for a large project.) I realize a lot of this time is stat-ing files, but it could be skipped and done manually later. "
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, Improvements to the user documentation, Integration with other build systems, Integration with other debuggers, Improvements to the build system, Better documentation in CDT code
Would like better documentation of the code and the internal structures, so as to make it not so daunting to develop my own additions or modifications.
Would also like better integration with Jam -- a mode for editing Jamfiles would be great, as well as a more general CDT awareness that in general a project that has an external build system (eg make, jam) will have more than one target.
Would be good if, when one has selected that indexing should be done according to the current configuration, that it didn't seem to spontaneously switch back to using a fixed configuration.
Should also be easier to start up embedded targets eg the ability to specify appropriate sequences to start the target -- for hosted gdb one starts a program with ""run"", but for many embedded targets that is not the case (eg the system is already running and you need only attach to it with ""target remote"", set up any required breakpoints then ""continue""). Some scriptability of how start-up proceeds would be good.
Q1: User
Q2: OpenSolaris x86/64
Q3: Improvements to the user documentation, Integration with other build systems, Integration with other compilers, Integration with other debuggers, DTrace
More integration with Solaris debugger and Sun compiler and build tools, and integration with DTrace on Solaris.
Q1: Developer
Q2: Linux
Q3: Improvements to the UI and usability, Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better documentation in CDT code, Better scalability and performance
We have a large code base so scalability can be an issue.
Q1: User
Q2: Windows
Q3: Integration with other compilers
I tried to get it to work with CygWin in the past and eventually gave up. MinGW works though.
Q1: Developer
Q2: Linux
Q3: More Refactorings and Source generation, Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better scalability and performance
.
Q1: User
Q2: Linux
Q3: Integration with other compilers, More Refactorings and Source generation, Better scalability and performance
none
Q1: User
Q2: Windows
Q3: More Refactorings and Source generation, Improvements to the editor and source navigation, Better scalability and performance
-
Q1: User
Q2: Windows
Q3: Improvements to the UI and usability, Integration with other compilers, More debugging features
Better support for GNU based cross compilers. Support for LLVM compiler. Remote debugging using, for example, OpenOCD or BDI2000 is difficult to the point that I'd rather use DDD or Insight.
Q1: User
Q2: Linux
Q3: Integration with other debuggers, More debugging features, Better stability, Better scalability and performance
Integration with the SuperTAP of the Freescale, Integration with the Trace32 of the Lauterbach Integrationwith GDB on the DDD level
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, More Refactorings and Source generation, Improvements to the build system, Better APIs for CDT developers, Better documentation in CDT code
Improvements to the UI and usability:
- Show callgraph as a graph instead of tree
- In the error console add folding so that long types in template errors ""std::basic_string<C, ...>"" can be folded into their short counterparts std::string (and expanded to investigate closer)
- When comparing .cproject files show a structured compare editor or a graphical diff
More Refactorings and Source generation:
- Organize Includes, e.g. remove unused ones
- Organize Using directives, e.g. remove unused ones
- More refactorings available via Quick-Fix
Improvements to the build system:
- Is headless build possible now?
Better APIs for CDT developers:
- We all want to become CDT developers!
Thanks for a wonderful product.
Q1: User
Q2: Linux
Q3: Improvements to the user documentation, More Refactorings and Source generation, More code analysis (optional in 7.0), Better stability, Better scalability and performance
Code analysis takes a long time on large projects, therefore I cannot use it every time I build which I would like to.
Q1: Developer
Q2: Linux
Q3: Improvements to the user documentation, Improvements to the build system, Better APIs for CDT developers, Better documentation in CDT code
Currently CDT integration with cross toolchains is extremely painful and limited. This situation must change since nowadays more and more people work with different architectures.
Q1: User
Q2: Linux
Q3: More Refactorings and Source generation, Improvements to the editor and source navigation, Better APIs for CDT developers, Better stability, Better scalability and performance
.
Q1: Developer
Q2: Linux
Q3: More debugging features, Improvements to the editor and source navigation
The ability to debug the code on target. Improve indexing to be faster.
Q1: Developer
Q2: Windows
Q3: Improvements to the UI and usability, Improvements to the user documentation, More Refactorings and Source generation, More debugging features, Improvements to the build system, More code analysis (optional in 7.0), Better APIs for CDT developers, Better documentation in CDT code, Better scalability and performance
It is hard to find any user documentation regarding headless build.
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, More Refactorings and Source generation, Improvements to the editor and source navigation, Better stability, Better scalability and performance
Eclipse getting stcuk often
Q1: User
Q2: Windows
Q3: Better scalability and performance
I use CDT (now 7.0) mostly for navigating and editing code in project counting 80000+ files. One of the problems is Eclipse/CDT locking up for 30 or more seconds on an occasion. This, at least sometimes, seems to be related to the code assists (either showing up automatically or when enabled manually). Also the ""Open Element"" is useless most of the time. When I type a known class name letter by letter too slowly it can't find it or takes indefinitely to update the list. However if open the ""Open Element"" window again and paste part of the class' name it finds it. Searching element using * doesn't work to good as well. So yeah, I think the focus should be refining current feature set (which is great) in context of scalability and performance.
Q1: User
Q2: Mac OS X
Q3: Improvements to the UI and usability, Integration with other build systems, Integration with other compilers, Integration with other debuggers, More Refactorings and Source generation, Improvements to the build system, Improvements to the editor and source navigation
Complex makefiles and directory structures
Q1: User
Q2: Linux
Q3: Integration with other build systems, More debugging features
Better integration with Qt qmake/uic/moc ...
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, Improvements to the build system, Improvements to the editor and source navigation, Better APIs for CDT developers, Better documentation in CDT code
Currently CDT is quite hard to handle without having deep knowledge of what we can do with it and how to do it. That goes for the general UI and build mechanism. About the UI, there are way too much views and menus everywhere. About the build system, lots of configurations and fields in the properties are really unclear & opaque, even to me who is an Eclipse expert & CDT user since a couple of years. Another need is from the API point of view as its really hard from a tooling developer to be able to extend or use CDT features. It's quite difficult to easily provide a new managed build configuration to integrate with embedded cross compiling tool chain.
Q1: User
Q2: Linux
Q3: More Refactorings and Source generation, More debugging features, Better scalability and performance
The debugger does not support well complex classes/structures (e.g. STL, Qt). The new pretty printing feature of gdb is only rudimentarily supported (e.g does not working for child elements).
Q1: Developer
Q2: Mac OS X
Q3: Integration with other build systems, Integration with other compilers, Integration with other debuggers, Better APIs for CDT developers, Better documentation in CDT code
I'm using CDT to integrated cross compiler targeting AmigaOS. (I'm doing it on my spare time). But always, when the integration of the amiga toolchain has be update or enhanced, i have the problem with where to start. My biggest problem is probably that i don't find the right documentation.
Q1: User
Q2: Mac OS X
Q3: Integration with other debuggers, Better scalability and performance
As a Mac OS X user, I want to have full support for apple's gdb so I don't have to resort to XCode for debugging.
As a Mac OS X user, I want to be able to start debugging at least as fast as in XCode so I don't waste so much time and I feel less pain using the CDT.
As a user using an external build script, I do not want eclipse to add any overhead (timewise) to running it so turnaround is faster because I am not forced to run the build script from the command line.
As a user building a large system, I want to be able to continue coding while a build is in progress and not have Eclipse lock up the workspace so I waste less time and have faster turnaround times.
Q1: User
Q2: Linux
Q3: Improvements to the UI and usability, Improvements to the editor and source navigation, Better stability, Better scalability and performance
.
Q1: User
Q2: Windows
Q3: Integration with other compilers, Integration with other debuggers, corss-compilation and debugging
Example for corss-compilation and debugging:
run CDT on Windows, build, compile debug on Linux
Q1: User
Q2: Linux
Q3: Improvements to the build system, Better stability, Better scalability and performance
We mainly use CDT for JNI and thus don't use CDT all that much, but when we do, we always have problems. CDT often rebuilds a project when nothing changed. We also need to support building for multiple platforms (Linux and AIX) from the same source project and we've had strange problems with multiple build configurations. We've also had problems where the generated make files were simply wrong. If we used CDT more and weren't so resource constrained, we might file bugs, but it's been our experience that bugs filed in the past were ignored.
Stability is our number one focus item. I challenge you to take care of your outstanding bugs.
Q1: User
Q2: Linux
Q3: More Refactorings and Source generation, More debugging features, Improvements to the build system, Improvements to the editor and source navigation, More code analysis (optional in 7.0)
still seeing hiccups often wrt eclipse/cdt talking with gdb (3.6/cdt7/ubuntu 9.10)
e.g.,
(1) say my binary under test segfault crashes, cdt sometimes (1 out of 5) misses it (and does not give a nice traceback)
(2) still seeing timeouts between cdt and gdb (eclipse pops up a dialog saying ""gdb timeout"" or something like that); it is intermittent: if I try again it usually works; I'd say maybe 1 out of 7 debug sessions will end up with this timeout dialog box; e.g., my debug sessions starts up just fine and am running in 'steady state' for, say, minutes, and then all of a sudden I get the ""gdb timeout"" dialog box
I do not have a feel for whether all of this is due to code bugs or perhaps configuration in preferences, e.g., gdb timeout settings, etc...
hope that helps- cdt rocks!!
Q1: User
Q2: Windows
Q3: Improvements to the build system
I am interested in the Makefile builds used with QNX Momentics.
A better grouping mechanism of projects.
Automatically delete the object files when changing the used header file."
Q1: Developer
Q2: Linux
Q3: More Refactorings and Source generation, Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better scalability and performance
Slowness of Eclipse compared to simpler editors like Emacs and Vim is the main barrier of entry for developers that are currently using other editors.
Q1: User
Q2: Linux
Q3: Integration with other build systems, More Refactorings and Source generation, Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better Qt support
Better CMake support For Qt: auto-completion for signals and slots (and maybe a checker) Doxygen hover similar to jdt's Javadoc hovers
Q1: User
Q2: Linux
Q3: Improvements to the user documentation, Integration with other build systems, More Refactorings and Source generation, More debugging features, Improvements to the build system, More code analysis (optional in 7.0), Better scalability and performance
cmake support
Q1: User
Q2: Windows
Q3: Improvements to the UI and usability, More Refactorings and Source generation, Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better documentation in CDT code, Full C++0x support
Better Website
Q1: Developer
Q2: Linux
Q3: Improvements to the editor and source navigation
I have 2 ideas for improvments: 1. Better way to find all the places that calls some function.(You have the option to click ctrl + left click, to find the decleration, I want to do the opposite). 2. Search for text in all files from some folder. For example, right click of the folder from the source panel, and ""Find in all files"".
Q1: User
Q2: Linux
Q3: Integration with other compilers, More debugging features, Improvements to the build system, virtual function editor indication/navigation
Full support Cross GCC Compilers Full support Python pretty printers
Add virtual function indication/navigation to the editor (like IntelliJ IDE)
Q1: Developer
Q2: Linux
Q3: Better documentation in CDT code
I'm developing a plug-in based on cdt and it's hard to find any relevant documentation.
Q1: User
Q2: Linux
Q3: Integration with other compilers, More Refactorings and Source generation, More code analysis (optional in 7.0)
While the current CDT C++ indexer does a great job, what I'd love to see is CDT offer the option to use Clang/LLVM for building and indexing, as in the XCode 4 beta.
Q1: User
Q2: Windows
Q3: Integration with other build systems, Integration with other compilers, Improvements to the build system, More code analysis (optional in 7.0), Better scalability and performance
- CMake and Visual C++ integration.
- Make it easy(-er) to specify toolchain locations if I have e.g. cygwin and mingw installed."
Q1: User
Q2: Linux
Q3: Improvements to the editor and source navigation, Better stability
Like CDT very much, been using it for years, here's a few things which I wish can be improved on:
1. ""compare->each other"" is a very useful tool, it would be more helpful if certain subdirectories can be excluded in comparison (such as Debug, Release, etc), right now, file types can be excluded by setting up in Preference;
2. File comparison calculation (CVS and SVN) sometimes become messy when there are many differences;
3. File type exclusion doesnt' work well for CVS synchronization, need to spend a lot of time adding those files to .cvsignore;
4. Code auto fill doesn't work well in Linux (ALT /), not like in windows version where the multiple selection menu can show up, it only fills a default word.
Thank you guys very much for making such a great platform.
Kun Shi
VeEX Inc. kshi@veexinc.com
Q1: User
Q2: Windows
Q3: Improvements to the user documentation, Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better scalability and performance, Working indexer and code completion on big projects!!
We are working on pretty huge projects (>2K source files) with external libraries and sources, etc. The indexer and code completion behaves really poor there. E.g. it does not "see" half of functions in the class, does not understand templates properly and more and more.
Q1: User
Q2: Linux
Q3: Better scalability and performance
nothing else to say
Q1: User
Q2: Windows
Q3: Integration with other debuggers, More debugging features, Improvements to the editor and source navigation, More code analysis (optional in 7.0)
I use CDT on linux and windows with cmake. It would be good if debugging could be more consistent/functional with both.
Better type hierarchy view collapsing hidden instances with a +, polymorphism (up/down) with a +, including file/line etc. More tree drilling perhaps?
Editor needs more basic text features, like sorting lines, selecting containing code block, inserting file, saving selected text. Pasting code needs automatic indentation. Not working at present. More advanced hover information would be good in editors (file/class/line in fine print above preview etc). Option to just navigate/load/show in other tab group editor without moving cursor or focus from current editor. Prioritise auto closing editors that have ""undo"" histories over those that don't -- being saved/modified is not important. The undo/redo history is a more reliable indication of current use/need. Option to navigate to automatically choose the first instance on include or source paths in current project before external projects, paths etc. Making choices all the time is annoying when I need to see what will be used when building. Feature to view all instances as per above if that is desired.
Codan could implement more eff c++ rules.
Codan could be expanded to check/compare consistency of style between all headers, source files. eg ""Sections"", layout, naming conventions."
Q1: User
Q2: Solaris
Q3: Improvements to the user documentation
Refactoring not well documented in CDT 7.0 user documentation.
Thoughts
Marc-Andre Laperle
"Scalability and Performance" was the most popular choice and I tend to agree that this is one of the biggest issue with CDT. Parsing and indexing could still be faster. I think it would be great to automate performance tests with big open source projects each week after the nightly build. For example, build the index of the Firefox source code and keep statistics. Other areas are also affected by performance problems. Just to name a few performance issues: Adding base classes in the class wizard, refactoring in general, invoking content assist (especially the first time), refresh after build. I suggest adding [performance] to bug titles to make them easier to spot for interested contributors.
"More Refactorings and Source generation" was also very popular. I think the refactoring component has a good start but right now it doesn't scale and it's often inaccurate. People coming from JDT also expect a lot more of them. I think improving the existing ones should be a top priority and it would be nice to have some new ones for 8.0. I'd be interested to learn what everyone think should be added. The test cases used for refactoring are often either small or simple - tests should be done on bigger and more complex projects (manually?).
"Improvements to the editor and source navigation": ...