Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
Requirements / Guidelines for re-writing the Code Completion
Michael:
--- Quote from: Takeshi Miya on December 21, 2005, 02:48:51 pm ---I think they redefine (by default) the new operator, for debugging purposes, which I think can be safely turned off.
--- End quote ---
Yes, it seems so. But still have some doubts in using STL with wxWidgets.
Michael
thomas:
I use STL a lot, because I hate wx containers. The blockallocator in Code::Blocks uses STL, the SVN plugin does, the Uservariable manager does... we compile tinyXML in STL mode, too (although we could do otherwise). Rick uses STL in his new tree class, the AStyle plugin uses STL if I remember correctly... just try and do a "find in files" on the project.
All you have to remember is to #undef new to undo the evil of wxWidgets *shudders*
Michael:
--- Quote from: thomas on December 21, 2005, 04:13:52 pm ---I use STL a lot, because I hate wx containers. The blockallocator in Code::Blocks uses STL, the SVN plugin does, the Uservariable manager does... we compile tinyXML in STL mode, too (although we could do otherwise). Rick uses STL in his new tree class, the AStyle plugin uses STL if I remember correctly... just try and do a "find in files" on the project.
--- End quote ---
That's is interesting. My doubts are vanishing :D. Probably, the problems I have had by using STL and wxWidgets have another source(s).
Michael
thomas:
Here are another few:
Parsing MUST be done in a separate thread.
Several threads MAY be used.
The parser thread(s) MUST have lower priority than the main thread.
The parser MUST NOT do insane things from the main thread. Events MUST be handed to the worker thread and MUST be handled there.
These requirements address the fact that save all files currently freezes the application for half a minute if you have a dozen modified files open. This is because the parser walks through the tokens array one by one and removes one token at a time for every file saved (causing ~250.000 memcpy() calls on a memory block half the total size of the tokens array). Furthermore, due to thread synchronisation, execution resumes only after all files have been parsed.
It does not matter at all that the actual parsing runs in a separate thread, the GUI still freezes for a time which is clearly longer than necessary and longer than acceptable. This will not change, even if we make parsing 500 times faster.
rickg22:
<i>These requirements address the fact that save all files currently freezes the application for half a minute if you have a dozen modified files open. This is because the parser walks through the tokens array one by one and removes one token at a time for every file saved</i>
THAT was what caused the freezes? Oh man! I knew it was bad, but not THAT bad! :?
I'll try to figure out how to fix it.
Edit: I'll post about this on another thread.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version