Yeah, we had that argument 2 years ago already. It hasn't happened yet.
Also, so far, the c++ codemodel has been geared towards producing code
completion and the class view, which is a bit different than the
context sensitive navigation of finding foo on bar.foo(). The best we
currently got is "Quick Open Method" but look at the implementation and
find that it is far from efficient.<br>
<br>
Ctags is of course far worse, it's all about brute force and doesn't understand C++ at all. It is however _very_ fast.<br>
<br>
There is also the fact that Ctags supports more than C/C++. 33
languages, in fact. At least half a dozen of which are relevant for
KDevelop3. See <a href="htttp://ctags.sourceforge.net/languages.html">htttp://ctags.sourceforge.net/languages.html</a><br><br>
There is considerable overlap between Ctags and the features that can come from the cpp parser, but CTags:<br>
1. works today <br>
2. works for more than C/C++<br>
3. is very fast<br>
4. is quite efficient, memory and cpu-wise.<br>
<br>
I say we keep it around a while longer.<br>
<br>
// jens<br>
<br>
<br><div><span class="gmail_quote">On 10/18/05, <b class="gmail_sendername">Adam Treat</b> <<a href="mailto:treat@kde.org">treat@kde.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Speaking of which, a few of us were talking about the idea of getting rid of<br>CTags altogether for the KDevelop4 branch.  There really is no reason that<br>the new parser can't handle this functionality.  One code database really
<br>should be enough and the user won't need to regenerate it manually.<br><br>Something to keep in mind.<br><br></blockquote></div><br>