Ollydbg,
I see the effort that you put into the CC and would like you to look at something that I think you can fix with regard to the CC.
The Allegro games programming library (www.liballeg.org (http://www.liballeg.org)) is my defacto games programming lib, and their macro usage within their library is insane!!! But hey, the thing works across more platforms than is considered sane, so I am giving them the benefit of the doubt.
Here is my problem:
All the functions within the library is declared with the following macros:
#ifndef AL_FUNC
#define AL_FUNC(type, name, args) type name args
#endif
#ifndef AL_PRINTFUNC
#define AL_PRINTFUNC(type, name, args, a, b) AL_FUNC(type, name, args)
#endif
#ifndef AL_METHOD
#define AL_METHOD(type, name, args) type (*name) args
#endif
#ifndef AL_FUNCPTR
#define AL_FUNCPTR(type, name, args) extern type (*name) args
#endif
#ifndef AL_FUNCPTRARRAY
#define AL_FUNCPTRARRAY(type, name, args) extern type (*name[]) args
#endif
#ifndef AL_INLINE
#define AL_INLINE(type, name, args, code) type name args;
#endif
It looks terribly insane, but is actually not! For example, if the following was declared:
AL_FUNC(int, drawpixel, (int x,int y, int color));
Then the final format of the argument when the preprocessor execution is finished looks like:
int drawpixel (int x,int y, int color);
Best regards,
For example, if the following was declared:
AL_FUNC(int, drawpixel, (int x,int y, int color));
Then the final format of the argument when the preprocessor execution is finished looks like:
int drawpixel (int x,int y, int color);
Best regards,
Ok, I understand your request.
First, I would say the "macro replacement" is really hard for the current CC, because there is not preprocessor in the current design. Although someone else is designing a preprocessor or there are several preprocessors on the net, but using preprocessor in CC will rapidly *slow* down the performance.
What's it offered is the "replacement token" functionality. say, if you have these code
AL_FUNC(int, drawpixel, (int x,int y, int color));
Then you have a replacement token "AL_FUNC" --> "xxxxx", then these code will regard as
xxxxx(int, drawpixel, (int x,int y, int color));
http://wiki.codeblocks.org/index.php?title=Code_Completion_Design#Return_a_correct_token.2C_Macro_replacement
Till now, Nothing more, but seems this can't solve your problem. :D
Some days ago, I have write a post to suggest a more sophisticated replacement in Tokenizer. That is what I have seen from source code of CTAGES. In these code, they have a more complex replacement function. This is something like Ctags' replacement options "−I identifier−list". see:
http://ctags.sourceforge.net/ctags.html#OPERATIONAL%20DETAILS
So, you can define the replacement token map like below:
"AL_FUNC" --> "+xxxxx"
"AL_FUNC1" --> "-yyyyy"
"AL_FUNC2" --> "*zzzzz"
......
Note, the first character of the map value can give the different macro extension method. For example, the "minus sign" suggest remove some string in the next string.
Back to your problem, I think the best way to write a custom replacement method.
when Tokenizer meets AL_FUNC, it should first return the token "int", next "drawpixel" , then "(int x,int y, int color)", so the high level lexer should give the right token sequence, and recognize them as a function declaration.
Another way, you can manual replace the m_Buffer in Tokenizer class, and remove the "," in AL_FUNC(int, drawpixel, (int x,int y, int color)); but that's more tricky.
Edit
I have changed a lot in that wiki page:
http://wiki.codeblocks.org/index.php?title=Code_Completion_Design
I have do some work for this.But it still have problem.
#define uii(a) unsigned a
uii(int) abd(int a) {}
int main()
{
abd//for me the abd can be recognized now.
return 0;
}
Ollydbg,
I see the effort that you put into the CC and would like you to look at something that I think you can fix with regard to the CC.
The Allegro games programming library (www.liballeg.org (http://www.liballeg.org)) is my defacto games programming lib, and their macro usage within their library is insane!!! But hey, the thing works across more platforms than is considered sane, so I am giving them the benefit of the doubt.
Here is my problem:
All the functions within the library is declared with the following macros:
#ifndef AL_FUNC
#define AL_FUNC(type, name, args) type name args
#endif
#ifndef AL_PRINTFUNC
#define AL_PRINTFUNC(type, name, args, a, b) AL_FUNC(type, name, args)
#endif
#ifndef AL_METHOD
#define AL_METHOD(type, name, args) type (*name) args
#endif
#ifndef AL_FUNCPTR
#define AL_FUNCPTR(type, name, args) extern type (*name) args
#endif
#ifndef AL_FUNCPTRARRAY
#define AL_FUNCPTRARRAY(type, name, args) extern type (*name[]) args
#endif
#ifndef AL_INLINE
#define AL_INLINE(type, name, args, code) type name args;
#endif
It looks terribly insane, but is actually not! For example, if the following was declared:
AL_FUNC(int, drawpixel, (int x,int y, int color));
Then the final format of the argument when the preprocessor execution is finished looks like:
int drawpixel (int x,int y, int color);
Best regards,
Hi, Here is a Good news!!!
I'm happy to test the code:
#ifndef AL_FUNC
#define AL_FUNC(type, name, args) type name args
#endif
#ifndef AL_PRINTFUNC
#define AL_PRINTFUNC(type, name, args, a, b) AL_FUNC(type, name, args)
#endif
#ifndef AL_METHOD
#define AL_METHOD(type, name, args) type (*name) args
#endif
#ifndef AL_FUNCPTR
#define AL_FUNCPTR(type, name, args) extern type (*name) args
#endif
#ifndef AL_FUNCPTRARRAY
#define AL_FUNCPTRARRAY(type, name, args) extern type (*name[]) args
#endif
#ifndef AL_INLINE
#define AL_INLINE(type, name, args, code) type name args;
#endif
AL_FUNC(int, drawpixel, (int x,int y, int color));
And here is the result:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2010-07-23221636.png)
This macro expansion and handling is mainly done by "loaden", you can tried it with the latest cc_branch. :D