| [cdt-dev] Analysis and solutions for Open Declaration/Definition: Introduction |
Our current product, Carbide.c++, is hosted on Windows and supports development for S60, which is built on Symbian OS. There's a quite large body of C++ code here, with sparing use of templates or macros, which should be an easy task for a good C++ parser. Unfortunately, we find the navigation to be unsatisfactory.
Under CDT 3.0, after a long indexing penalty, hardly any symbols' declarations could be opened using F3. I was glad to find that CDT 3.1.1 indeed has much better performance with the Fast Indexer (about 10-15 seconds for ~1800 files), but perplexed that this navigation still didn't work very consistently. A gaggle of bug reports seems to confirm my experience, though strangely, they seem to be dormant.
I did some investigation against the cdt_3_1 branch to find why these commands had such spotty performance (see bugs 142031, 130740 for some, as well as recent messages on this list). I tested using the Fast Indexer in Standard Make projects to eliminate project configuration variables as much as possible. (The analysis and solutions apply unchanged to the head.)
Messages will follow for each issue, so they can be discussed separately. These represent a few days of research and certainly more will follow.
I'd be interested in any feedback regarding any work currently being done in this area and how these changes may fit in. My work is merely the result of (educated) hacking around and may precipitate more widespread changes, but I couldn't say, though certainly nothing was worse after making them.
After discussion and approval here, I'm planning on submitting patches to bugzilla. Recommendations for whether to add patches to existing reports or make new ones is welcome. Regarding patches, some additional coding questions not covered elsewhere: are there any internal interfaces that might be made public that I should steer clear of? Or do some internal interfaces have a 'nearly-frozen' state? And what allowances are there for adding or extending the behavior of public APIs? Finally, I'd like to get advice on contributing useful unit tests and know how this may impact what dictates an acceptable change.
At a minimum, someone more qualified can use my findings as a reference. ;)
-- Ed