Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

CC Macro enhancement required for Allegro

(1/2) > >>

joubertdj:
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) 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:

--- 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

--- End code ---

It looks terribly insane, but is actually not! For example, if the following was declared:


--- Code: ---AL_FUNC(int, drawpixel, (int x,int y, int color));

--- End code ---

Then the final format of the argument when the preprocessor execution is finished looks like:

--- Code: ---int drawpixel (int x,int y, int color);

--- End code ---
Unfortunately our "Replacement tokens" do not facilitate the arguments in question. Do you by any chance have a suggestion or idea how the CC could handle such Macro arguments?

Best regards,

ollydbg:

--- Quote from: joubertdj on July 11, 2009, 10:46:33 pm ---For example, if the following was declared:


--- Code: ---AL_FUNC(int, drawpixel, (int x,int y, int color));

--- End code ---

Then the final format of the argument when the preprocessor execution is finished looks like:

--- Code: ---int drawpixel (int x,int y, int color);

--- End code ---
Unfortunately our "Replacement tokens" do not facilitate the arguments in question. Do you by any chance have a suggestion or idea how the CC could handle such Macro arguments?

Best regards,

--- End quote ---

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

--- Code: ---AL_FUNC(int, drawpixel, (int x,int y, int color));

--- End code ---

Then you have a replacement token "AL_FUNC" --> "xxxxx", then these code will regard as

--- Code: ---xxxxx(int, drawpixel, (int x,int y, int color));

--- End code ---
This is done by the Tokenizer class, you can see some details in the wiki page:
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:


--- Code: ---"AL_FUNC" --> "+xxxxx"
"AL_FUNC1" --> "-yyyyy"
"AL_FUNC2" --> "*zzzzz"
......

--- End code ---

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

blueshake:
I have do some work for this.But it still have problem.

--- Code: ---#define uii(a) unsigned a
uii(int) abd(int a) {}

int main()
{
abd//for me the abd can be recognized now.
    return 0;
}
--- End code ---

ollydbg:
@blueshake

--- Code: ---uii(int) abd(int a) {}

--- End code ---
The code above can be recognized correctly if you use the current CC_branch. Morten has applied a patch I created several months ago, that was to solve a similar problem in dealing with OpenCV function prototype. :D

If you use another way, I'm grad to see.

joubertdj:
Ollydbg,

Have you ever looked at Wave from Boost: http://www.boost.org/doc/libs/1_39_0/libs/wave/index.html

It looks like a proper pre-processor that "can" be used within other projects such as ours?

Best regards,

Navigation

[0] Message Index

[#] Next page

Go to full version