Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
New code completion remarks/issues
blueshake:
hi,mortern:
can you comment these codes,because they make no sense.
--- Code: ---Index: src/plugins/codecompletion/parser/parserthread.cpp
===================================================================
--- src/plugins/codecompletion/parser/parserthread.cpp (revision 5986)
+++ src/plugins/codecompletion/parser/parserthread.cpp (working copy)
@@ -661,17 +661,17 @@
&& (!m_pLastParent || m_pLastParent->m_Name != token) ) // if func has same name as current scope (class)
{
// test Macro
- if (token.Upper() == token)
+ /*if (token.Upper() == token)
{
HandleMacro(token, peek);
m_Tokenizer.GetToken();
m_Str.Clear();
}
else
- {
+ {*/
wxString arg = m_Tokenizer.GetToken(); // eat args ()
m_Str = token+arg;
- }
+ //}
}
else if (peek.GetChar(0) == '(' && m_Options.handleFunctions)
{
--- End code ---
MortenMacFly:
--- Quote from: blueshake on December 25, 2009, 06:20:57 am ---can you comment these codes,because they make no sense.
--- End quote ---
Why exactly does that make no sense? Because if commented macros are not being handeled at all.
blueshake:
check this
--- Code: ---if (token.Upper() == token)
--- End code ---
it make a hypothesis here that all macro should be capital,but if the macros are not capital letters,this will not work.
for example:
LINUX(ARG) ---------------work.
linUX(ARG) ----------------not work
and in this situation,should in using macro but not defining a macro.so it is no reason to add macro here.
MortenMacFly:
--- Quote from: blueshake on December 25, 2009, 12:40:47 pm ---LINUX(ARG) ---------------work.
linUX(ARG) ----------------not work
--- End quote ---
This is true, however, macros are usually uppercase it's like a rule everybody should follow. In addition it worked nicely for me for quite some macros that were CC'ed very nicely afterwards. However, I agree that the detection algorithm should be more precise. So I'll comment it for a while and add a ToDo there...
Pending changes will be committed a little later... I am still testing some other CC related stuff (including your other patch...).
Techy:
Hi,
I started experiencing quite serious performance issue after rev. 5945 for big projects. To be more precise - the code that 5945 introduced doesn't cause the problem - it just made the problem more visible. What happened after this commit was that the number of enums found in the project increased to about 18000 (this looks like a correct number - I was grepping through the whole project and there are about 60000 occurrences of enum there - some possibly comments so this seems to be more or less OK). Parsing is quite fast (about 10s), but then the whole GUI freezes for about 40 seconds (CPU 100%). This happens even when re-saving a file (parsing 0.1s), but again the whole 40s freeze of the GUI. I experienced this before as well, but the freeze took only 2 seconds so I thought it was the old Linux I was using.
OK, what happens - parsing is really fast and because it runs in a separate thread, id doesn't block the GUI. However, when parsing is finished, NativeParser::OnParserEnd is invoked and there parser->LinkInheritance(false) is called, which is the thing that takes the terrible amount of time. So my question is:
1. Could this function be called only when "Display inheritance info" is selected in the options page or "Show inherited members" is selected from the right-click menu? Is the info used by calling this function used by something else as well? (I'm running codeblocks with the problematic command commented-out now without any major issue so I guess this should be possible). It would be good to be able to at least disable it.
2. Could this thing be performed in the parser thread? This at least wouldn't freeze the GUI. (Again, I think this might be possible as well.)
3. Could this function be done in a smarter way? For instance building the complete tree only once at the beginning and adding the classes from the saved file to the hierarchy. I haven't studied the algorithm of this thing in detail yet but I think it has quadratic complexity (at least when thinking how to implement it, the most trivial way has quadratic complexity). This maybe could be improved as well. Finally, I've seen that TokensTree::RecalcData() goes through all classes, typedefs and enums - only typedefs for classes and structs are interesting for this function so the rest could be filtered out. Why are the enums there? (Again, I haven't studied this in detail so maybe the above is done already - just putting some ideas I have here).
Your opinion?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version