Ting 이네 Software 이야기

(*1)

// File : "main"

enum
{
    enum01,
    enum02,
    ...
}
...

This is not recommended.
How about using following way?

(*2)

// File : "enum.h "

DEF_ENUM(enum01)
DEF_ENUM(enum02)
...

------------------

// File : "main

#define DEF_ENUM(x)   x,
enum
{
    #include "enum.h"
}
#undef DEF_ENUM

Why this way is better? Let's assume that you want to print 'enum' values.
In (*1) case, only number value can be printed. But in (*2) case, even enum name - string - can be easily printed by following way.

// File : "Enum_str.c"

#define DEF_ENUM(x)   #x,
static const char* enum_str[] =
{
    #include "enum.h"
};
...

printf("%s", enum_str[enum_id]);

It is good, isn't it?
Except for this, you can find other lots of useful ways by using macro.

====================================================

// From MSDN

#define paster( n ) printf( "token" #n " = %d", token##n )
int token9 = 9;

If a macro is called with a numeric argument like

paster( 9 );

the macro yields

printf( "token" "9" " = %d", token9 );

which becomes

printf( "token9 = %d", token9 );

====================================================

',' is used as parameter separator in C/C++. So, function which uses variable number of parameter - like "logger(const char* format, ...)" - is difficult to present by using macro. (Some compilers support variable number of parameter in macro too. But, most are not.)
In this case, we can make those be on parameter by groupping all parameters with "()".
For example,

#ifdef _DEBUG_
#   define LOGGER(X) logger X
#else // _DEBUG_
// we don't need to run log function in release build!
#   define LOGGER(X)
#endif // _DEBUG_
...
LOGGER((”print :%d, %d”, a, b)); // == logger(“print:%d, %d”, a, b);
...

=====================================================

To track a function, following way is very common.

// foo_fnc. h :
#ifdef CODE_DEBUG
#   define REAL_fnc(a, b) real_fnc(a, b, __FILE__, __LINE__)
#else
#   define REAL_fnc(a,b) real_fnc(a,b)
#endif

But, In following cases, some compiler raises error.

#ifdef 1
REAL_fnc(a,
#else
NEW_REAL_fnc(a,
#endif
    b);

Yes. It's a kind of porting issue.
In this case, we can use following walk-around.

// foo_fnc. h :
#ifdef CODE_DEBUG
    typedef int (* RealType_Fnc)(int, int)
#   define REAL_fnc real_fnc_wrap(__FILE__, __LINE__)
    extern RealType_Fnc real_fnc_wrap(char*, int);
#else
#   define REAL_fnc(a,b) real_fnc(a,b)
#endif

---------

// foo_fnc.c
...(omitted)
RealType_Fnc real_fnc_wrap(char* fileName, int line)
{
    printf(“%s : %d”, fileName, line);
    return real_fnc;
}

Before unrolling, we should consider followings.
1. Unrolling increases code size. So, we should consider instruction cache size. That is, we should unroll code without decreasing cache hit rate.
2. What is best unrolling value? Some reports said that '16'(16 operations per one loop) is enough.

And, here is coding example for unrolling.

#define UNROLL8( x, s, cond ) \
do { \
    switch( (s) & 0x7 ) \
    { \
        case 0: do  \
                {  \
                    x; \
        case 7:     x; \
        case 6:     x; \
        case 5:     x; \
        case 4:     x; \
        case 3:     x; \
        case 2:     x; \
        case 1:     x; \
            } while( cond ); \
    } \
} while(0)

Usage : UNROLL8(*dst = *src; dst++; src++;, loop_count, dst < dst_end)