News:

Accounts with zero posts and zero activity during the last months will be deleted periodically to fight SPAM!

Main Menu

Partial C/C++ preprocessor function for codecompletion

Started by nullwu, October 22, 2009, 10:20:04 PM

Previous topic - Next topic

nullwu

Hi all

English isn't my native language, so... :oops:

I made a patch for codecompletion, which implement some preprocessor function.
Maybe it's not necessary for somebody, but I do need. Or ... do I miss something???


features:
1. accept simple macro definition.
2. branch to "almost" right decision. (because the definition stored in macro still incomplete)
3. disabled block "highlight".
4. header files dependency calculation, let parsing sequence of source files more proper.

I tested this fragment of code under Pentium-M 1.2G box with
WindowXP + TDM gcc 4.4.0  & coLinux + gentoo + gcc 4.1.2
and wxWidgets 2.8.10 for sure.


[UPDATE]
sorry, my bad, the previous patch will disable the function browse in toolbar
here is the new patch


[attachment deleted by admin]

ollydbg

 :D
Thanks!!!
This is a so big patch. I will take time to check it.
Also, It seems the patch is against debugger_branch. :D

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

MortenMacFly

Here are my 2 cents (questions) from a look I had so far. Notice that I didn't try yet, I just looked at the code.

1.) Why exactly are you using the scripting engine? I didn't get the reason for that from a quick look. This surely makes the processing (of whatever) quite slow.

2.) You are accessing UI controls out of the parser thread (ParserThread::PreprocessorStyling). This will surely lead into a crash sooner or later. Why are you doing so?

Besides that it looks really interesting. I am looking forward to give it a try... :-)
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

ollydbg

Quote from: MortenMacFly on October 23, 2009, 07:07:13 AM
1.) Why exactly are you using the scripting engine? I didn't get the reason for that from a quick look. This surely makes the processing (of whatever) quite slow.
This is the question I would like to ask either.

I'm not fully understand the whole code, but it seems the author use the Sq script engine to evaluate the #if condition's value.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Ceniza

Quote from: ollydbg on October 23, 2009, 07:20:53 AM
Quote from: MortenMacFly on October 23, 2009, 07:07:13 AM
1.) Why exactly are you using the scripting engine? I didn't get the reason for that from a quick look. This surely makes the processing (of whatever) quite slow.
This is the question I would like to ask either.

I'm not fully understand the whole code, but it seems the author use the Sq script engine to evaluate the #if condition's value.

If that's all he uses scripting for, my template abusive implementation of a preprocessor has the code to evaluate that in the file constexprevaluator.h.

I started to convert the code to something easier to understand (by removing all the template code), but that file is not yet converted. It works only up to the PPLexer now (Preprocessor and Lexer are still unconverted).

nullwu

Quote from: ollydbg on October 23, 2009, 02:52:58 AM
<...deleted...>
Also, It seems the patch is against debugger_branch. :D
No, I always merge with trunk. but I'm watching the debugger branch too.

Quote from: MortenMacFly on October 23, 2009, 07:07:13 AM
1.) Why exactly are you using the scripting engine? I didn't get the reason for that from a quick look. This surely makes the processing (of whatever) quite slow.
2.) You are accessing UI controls out of the parser thread (ParserThread::PreprocessorStyling). This will surely lead into a crash sooner or later. Why are you doing so?
Yes, scripting engine will slow down parsing, but it's result will guide CC to override some unnecessary parsing, it's worthy.
The PreprocessorStryling() is activated only under ParseBuffer* , so far, these series are called only from main thread. So it's safe for now.

Quote from: Ceniza on October 23, 2009, 09:34:09 AM
Quote from: ollydbg on October 23, 2009, 07:20:53 AM
Quote from: MortenMacFly on October 23, 2009, 07:07:13 AM
<...>
This is the question I would like to ask either.

I'm not fully understand the whole code, but it seems the author use the Sq script engine to evaluate the #if condition's value.

If that's all he uses scripting for, my template abusive implementation of a preprocessor has the code to evaluate that in the file constexprevaluator.h.
<...>
Yes, that's all I use scripting for.


finally, something needs more description,
It needs reparsing 2~4 times when the project is the first time to load.
After batch parsing(reparsing), it will (re)produce a <proj>.ccdepend file.
It just calculate the 'header file' dependency, not macro, it does not maintain a exact define-use chain.

MortenMacFly

Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: [url="https://www.codeblocks.org/docs/main_codeblocks_en.html"]https://www.codeblocks.org/docs/main_codeblocks_en.html[/url]
C::B FAQ: [url="https://wiki.codeblocks.org/index.php?title=FAQ"]https://wiki.codeblocks.org/index.php?title=FAQ[/url]

Ceniza