Community
Participate
Working Groups
During my using cdt for about 2 months, the most boresome thing is C/C++ Indexer.It's main problem is its speed and cpu usage, on my AthlonXP 2200+/512DDR machine, sometimes it costs about 40-60 minutes to index about 480 c++ files, sometimes it suspends and all the other apps can't response for operation too so i have to restart machine! But the nightmare has not ended! Even I complete index all the files fortunately, the "C/C++ Search" works not well yet. For example, it maybe can't search a variable declaration out, but it just be on the screen and under my eye! Whatmore, i found C/C++ Browsing also have bug, like some classes' member view is empty but actually should show 20 members there! I think all these bug are produced by C/C++ Inderxer. I really hope it will be well settled down at next cdt release.
Scalability and perfomance complaints aside, we will need to understand a bit more about your project in order to solve the correctness issues regarding the Search & Class Browser features. Are you using gcc? Are you cross compiling? Do you have your include paths and macros discovered properly? Do you add any additional include paths? Are you using Standard or Managed Make? Is your project primarily C or C++ source?
Indexing feature is failing to work in M5 release. Are you using gcc? yes gcc4.0.0 Are you cross compiling? no Do you have your include paths and macros discovered properly? Yes Do you add any additional include paths? needed to add one path for libxml Are you using Standard or Managed Make? Standard Is your project primarily C or C++ source? C current actions-- after a file save or build indexer thinks about 2 seconds yet outline is left blank and code completions fail.
David - A few more things for you to check - right click on your project and bring up the properties; go to the indexer tab. Make sure taht "Original C/C++ Indexer" is selected in the indexer box and that index enabled is checked. You can then verify that the index is working by performing a search. Note that content assist and outline view are not driven by the indexer.
I just 1. Restarted eclipse. 2. Closed and repoend project in question. 3. Verified "Original C/C++ Indexer" is selected in the indexer box. 4. Verified that index enabled is checked. 5. Rebuilt project. 6. Tried to search for repo_set (a very common variable). Resulted in zero occurances found. >Note that content assist and outline view are not driven by the indexer. Sorry, all three failed at the same time -- I assumed there was a relationship between the three.
follow up -- the Indexer is taking about 10-15 seconds to process the project, which is about what it was taking before I noticed the problem.
Two more things to try: 1. After making sure that the indexer is enabled, close the project and reopen it (this will force a complete reindex of the project). 2. If you still don't get any results with that, you can try turning on IProblems which will cause the indexer to create markers for all problems encountered by the parser while processing your project.
Thanks, I just 1. Verified all three c/c++ index problem reporting boxes were checked. 2. Restarted project. 3. Two warning found. 4. Fixed cause of warnings. 5. Rebuilt & closed & reopened project. 6. Indexer ran for 15 seconds. 7. 0 error, 0 warning, 0 infos. 8. Tried to search for repo_set (a very common variable). Resulted in zero occurances found.
Do you get any results for any other searches? (Try a search on * Any Element/All Occurrences).
I have tried many different searches with different parameters. None had hits until I searched on '* Any Element/All Occurrences' which resulted in the following SIGSTOP ( /usr/include/bits/signum.h ) (1 match) SI_ASYNCNL ( /usr/include/bits/siginfo.h ) (1 match) getusershell(void) ( /usr/include/unistd.h ) (1 match) isspace ( /usr/include/ctype.h ) (1 match) ECONNABORTED ( /usr/include/asm/errno.h ) (1 match) EPROTONOSUPPORT ( /usr/include/asm/errno.h ) (1 match) _POSIX_CLOCK_SELECTION ( /usr/include/bits/posix_opt.h ) (1 match) USHRT_MAX ( /usr/lib/gcc/i386-redhat-linux/4.0.0/include/limits.h ) (1 match) ... <2,000 odd lines clipped for brevity> All search found were symbols in the discovered include path. It didn't find any hits in either project *.h's or *.c's weird.
This sounds like it could be related to bug 69078.
Well, this is a very vague bug. The new "Fast" indexer should hopefully address these concerns. Please raise detailed individual bugs if you find anything wrong.
