The choice for allow semicolons on Macros

addons_zz · **Author**

The choice for allow semicolons on Macros

I use this macro, which should allow it to remove the 'server_print(...)'
statements completely from the code:

Code:

/**
 * This is to view internal...
 *
 * ...
 * 31  - Levels 1, 2, 4 and 8.
 * 
 * Default value: 0
 */
#define DEBUG_LEVEL 0
/**
 * Setup the debugging tools when they are used/necessary.
 */
#if DEBUG_LEVEL & ( DEBUG_LEVEL_NORMAL | DEBUG_LEVEL_CRITICAL_MODE )
    #define DEBUG
    #define LOGGER(%1) debugMesssageLogger( %1 )    
    /**
     * ...
     * 128  - Functions entrances messages.
     * 255  - Enables all debug logging levels.
     */
    new g_debug_level = 1 + 4 + 8 + 16;
    
    
    /**
     * Write debug messages accordantly with the 'g_debug_level' variable.
     *
     * @param mode the debug mode level, see the variable 'g_debug_level' for the levels.
     * @param text the debug message, if omitted its default value is ""
     * @param any the variable number of formatting parameters
     * 
     * @see the stock writeToTheDebugFile( log_file[], formated_message[] ) for the output log "_galileo.log".
     */
    stock debugMesssageLogger( const mode, const message[] = "", any:... )
    {
        if( mode & g_debug_level )
        {
            static formated_message[ MAX_BIG_BOSS_STRING ];
            vformat( formated_message, charsmax( formated_message ), message, 3 );
            
            writeToTheDebugFile( "_galileo.log", formated_message );
        }
    }
#else
    #define LOGGER(%1) allowToUseSemicolonOnMacrosEnd()    
    stock allowToUseSemicolonOnMacrosEnd()
    {
    }
    
#endif

Now the options

1st

When disabling the debug, we need to set the '#define LOGGER(%1)' to something. On the above code,
it is being setted to 'allowToUseSemicolonOnMacrosEnd()'. But is not what we want to, when disabling
the debug, because it still inserting instructions on the binary code. More precisely, this assembly instructions:

Code:

    proc    ; cmd_go
    break   ; 8c
    break   ; 90
    push.c 0
    call allowToUseSemicolonOnMacrosEnd
    ;$exp
    zero.pri
    retn

    proc    ; allowToUseSemicolonOnMacrosEnd
    break   ; b0
    zero.pri
    retn

For this code:

Code:

public cmd_go()
{
    allowToUseSemicolonOnMacrosEnd();
}

stock allowToUseSemicolonOnMacrosEnd()
{
}

2nd

On second place, is accepted to use:

Code:

new const bool:g_dummy_value = false;

public cmd_go()
{
    do { } while( g_dummy_value );
}

Which generates the following code:

Code:

    proc    ; cmd_go
    break   ; 8c
    break   ; 90
l.9a        ; 94
l.98        ; 94
    break   ; 94
    load.pri 0
    jzer 99
    ;$exp
    jump 9a
l.99        ; b0
    zero.pri
    retn

Which does not look good, though.

3rd

At third, can be thought of:

Code:

new g_dummy_value;

public cmd_go()
{
    g_dummy_value;
}

And generates:

Code:

    proc    ; cmd_go
    break   ; 8c
    break   ; 90
    load.pri 0
    ;$exp
    zero.pri
    retn

Does not look good enough, thought. It is supposed to be nothing, instead of 'load.pri 0'.
And this is very pain in the ass, as the compiler shows to each use a dawn warning:

Code:

: warning 215: expression has no effect

4th

Using a increment operation would remove the warning:

Code:

new g_dummy_value;

public cmd_go()
{
    g_dummy_value++;
}

Generating:

Code:

    proc    ; cmd_go
    break   ; 8c
    break   ; 90
    inc 0
    ;$exp
    zero.pri
    retn

The difference from this to the 3rd option which was 'load.pri 0', is 'inc 0'. So, instead of
just placing zeros on the 'pri' register, we are now incrementing a variable on the '0' address.

Ending

Would be awesome if I could use something like this:

Code:

    #define LOGGER(%1) //
or
    #define LOGGER(%1)

When disabling macros for the 'DEBUG_LEVEL' 0. But it does not work, and it is ignored. The compiler
keeps throwing the error:

Code:

: error 036: empty statement

This is happening because every line on the code, including the 'LOGGER' macros ending, are using
semicolons, then when the preprocessor removes the macros for the 'DEBUG_LEVEL' 0, the several lines
end up with the empty statement error.

Here are the profiler timing for the macros alternatives:

Code:

date: Tue Jul 19 22:36:01 2016 map: de_dust2
type |                             name |      calls | time / min / max
-------------------------------------------------------------------
   n |                  register_plugin |          1 | 0.000005 / 0.000005 / 0.000005
   n |                  register_srvcmd |          1 | 0.000036 / 0.000036 / 0.000036
   n |                       server_cmd |          1 | 0.000005 / 0.000005 / 0.000005
   p |                           cmd_go |          1 | 0.000002 / 0.000002 / 0.000002
   p |                      plugin_init |          1 | 0.000002 / 0.000002 / 0.000002
   f |                    callOnlyMacro |          1 | 0.079895 / 0.079895 / 0.079895
   f |                  callMother_fuke |          1 | 0.089007 / 0.089007 / 0.089007
   f |                  callOnMacrosEnd |          1 | 0.897962 / 0.897962 / 0.897962
   f |   allowToUseSemicolonOnMacrosEnd |   10000000 | 0.890177 / 0.000000 / 0.001022
0 natives, 0 public callbacks, 2 function calls were not executed.

'callOnMacrosEnd' is the 1st above option.
'callOnlyMacro' is the 2nd above option.
'callMother_fuke' is the 4th above option.

This was the source code used:

Spoiler

Results

I can remove the semicolons from the macros ending, then the option:

Code:

    #define LOGGER(%1)

Will work just fine, because there will be any ': error 036: empty statement'.

I want to keep adding semicolons to the macros ending to keep a pattern on the source code,
putting everything which looks like instructions under the same design.

If I keep the semicolon on the macros ending, I need to use one of the options 1, 2, 3 and 4 above.
I want to keep the semicolons, then it is acceptable to use some the those options?

Or do you know something I am missing and could allow to add semicolons to the macros
ending, allowing them to be enabled or disabled by the 'DEBUG_LEVEL' variable?