CC Macro enhancement required for Allegro

[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

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

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

Code

int drawpixel (int x,int y, int color);

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]

For example, if the following was declared:

Code

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:

Code

int drawpixel (int x,int y, int color);

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,

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

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

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.

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

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

[ollydbg]

@blueshake

Code

uii(int) abd(int a) {}

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.

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,

[ollydbg]

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,

Hi, I have noticed that, also, many other pre-processors can be found on the internet. But, I think using wave is really “beyond my current programming level", so.

[ollydbg]

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

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

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

Code

int drawpixel (int x,int y, int color);

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,

Hi, Here is a Good news!!!

I'm happy to test the code:

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:


This macro expansion and handling is mainly done by "loaden", you can tried it with the latest cc_branch.

[joubertdj]

  Whoop!!!!!!!

Any idea when you will be merging into the main branch for "additional" testing?