Author Topic: CC Macro enhancement required for Allegro  (Read 15839 times)

Offline joubertdj

  • Multiple posting newcomer
  • *
  • Posts: 120
CC Macro enhancement required for Allegro
« on: July 11, 2009, 10:46:33 pm »
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,

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6036
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CC Macro enhancement required for Allegro
« Reply #1 on: July 12, 2009, 08:50:06 am »
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. :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"
......

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
« Last Edit: July 12, 2009, 03:33:42 pm by ollydbg »
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.

Offline blueshake

  • Regular
  • ***
  • Posts: 459
Re: CC Macro enhancement required for Allegro
« Reply #2 on: July 13, 2009, 09:04:39 am »
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;
}
Keep low and hear the sadness of little dog.
I fall in love with a girl,but I don't dare to tell her.What should I do?

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6036
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CC Macro enhancement required for Allegro
« Reply #3 on: July 14, 2009, 01:54:09 pm »
@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. :D

If you use another way, I'm grad to see.
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.

Offline joubertdj

  • Multiple posting newcomer
  • *
  • Posts: 120
Re: CC Macro enhancement required for Allegro
« Reply #4 on: July 22, 2009, 10:39:44 pm »
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,

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6036
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CC Macro enhancement required for Allegro
« Reply #5 on: July 23, 2009, 05:04:21 pm »
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. :(

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.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6036
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: CC Macro enhancement required for Allegro
« Reply #6 on: July 23, 2010, 04:20:58 pm »
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. :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.

Offline joubertdj

  • Multiple posting newcomer
  • *
  • Posts: 120
Re: CC Macro enhancement required for Allegro
« Reply #7 on: August 02, 2010, 12:36:59 pm »
 :D Whoop!!!!!!!

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