View source for CDT/Archive/survey/2010


{{warning|Note: The contents of this page refer to planning documents of past Eclipse CDT releases. See [[CDT/planning]] for current information. }}

[[Category:CDT:Archive]]

== Are you a CDT user or developer (CDT or CDT-based product)? ==
[[Image:CDT-Survey2010-q1-chart.png]]

*User		47 (71%)
*Developer	19 (29%)

== On which platform do you use CDT the most? ==

[[Image:CDT-Survey2010-q2-chart.png]]

*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) ? ==

[[Image:CDT-Survey2010-q3-chart.png]]

*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<br>
Q2: Mac OS X<br>
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<br>
Q2: Mac OS X<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
Q3: Improvements to the editor and source navigation, More code analysis (optional in 7.0), Better stability, Better scalability and performance

a
----
Q1: Developer<br>
Q2: Windows<br>
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<br>
Q2: Widows primarily but also Linux (and maybe Solaris)<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
Q3: Improvements to the user documentation, More debugging features

Multi-core debugging
----
Q1: User<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: OpenSolaris x86/64<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
Q3: Integration with other compilers, More Refactorings and Source generation, Better scalability and performance

none
----
Q1: User<br>
Q2: Windows<br>
Q3: More Refactorings and Source generation, Improvements to the editor and source navigation, Better scalability and performance

-
----
Q1: User<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Mac OS X<br>
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<br>
Q2: Linux<br>
Q3: Integration with other build systems, More debugging features

Better integration with Qt qmake/uic/moc ...
----
Q1: User<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Mac OS X<br>
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<br>
Q2: Mac OS X<br>
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<br>
Q2: Linux<br>
Q3: Improvements to the UI and usability, Improvements to the editor and source navigation, Better stability, Better scalability and performance

.
----
Q1: User<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
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<br>
Q2: Windows<br>
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<br>
Q2: Linux<br>
Q3: Better scalability and performance

nothing else to say
----
Q1: User<br>
Q2: Windows<br>
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<br>
Q2: Solaris<br>
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": ...