Error C213

For the purposes of debugging, you should take your macro "calls" and replace them with the individual construct. That is, put the defined do{}while(0); in the main code and try to compile it rather than using the macros.

My suspicion is that when you do this, it will reveal something about the way the compiler is interpreting your macros, and you'll see where the real problem lies.

For the purposes of debugging, you should take your macro "calls" and replace them with the individual construct. That is, put the defined do{}while(0); in the main code and try to compile it rather than using the macros.

My suspicion is that when you do this, it will reveal something about the way the compiler is interpreting your macros, and you'll see where the real problem lies.

I actually think this sort of thing is justifiable if you comment it up properly. For instance, it can achieve the equivalent of C++'s "inline" functions in C. If you have a "function" to call a bunch of places that's very simple, then just injecting the 9 or 10 actual instructions everywhere gets a bit ugly. Also, if the timing is of some importance, they may be used at places where you don't want the overhead of a function call.

You totally do not get the point, nobody (or at lest not I) have a problem with using a macro to achieve the above.

The issue is "making the macro look like a function call" which is a wonderful way to obfusciate the code.

Erik

"The issue is "making the macro look like a function call" which is a wonderful way to obfusciate the code."

I don't know, the caps in the macro name scream 'MACRO!' to me.

....obfusciate the code."

I don't know, the caps in the macro name scream 'MACRO!' to me.

If you "scream" macro, the why use the do_while_0 which have no other purpose than to make it look like a function call?

Erik

Many C programmers do not realize that you can declare local blocks inside functions. That is,

void main (void)
    {
    int i;

    // code goes here

    { // local block
    int j;

    // some code
    } // end of local block

    // more code goes here

    } // main

    switch (msg->type)
        {
        case MsgTypeA :
            {
            MsgA* msgA = (MsgA*)msg;
            // variables for handling msg A

            msgA->fieldA...
            }
            break;

        case MsgTypeB :
            {
            MsgB* msgB = (MsgB*)msg;
            // vars needed only for B

            msgB->fieldB...
            }
            break;

        default :
            break;
        }

Erik,

I understand now. Leaving off the () at the end would be a nice way to clue people in that it was a macro, I agree.

Another place I find local blocks handy is in switch statements.

Well I guess we know Drew is among those of us with the misfortune to have written a Windows WndProc or two. :)

The issue is "making the macro look like a function call" which is a wonderful way to obfusciate the code.

You've let yourself get confused. This is not about adding obfuscation, but about keeping it under control.

The goal of the do..while(0) trick is not to make the macro call look like a function call --- the mere fact of it being a function-like macro with a parameter list already achieves that.

The actual goal is to make the macro invocation not just look like a function call (including an argument list), but also actually act like one, in all possible contexts. The tricky one being

if (foo)
  MYMACRO(bar,2,3,4);
else
  do_something_else(bar,4,3,2);

we know Drew has written a WndProc

Well, I will admit to having written a WndProc or two in my checkered past. Mostly I do embedded communications stuff not related to Windows, though. That sort of switch statement is a common pattern for me. That may just mean I'm in a rut, of course, but there always seems to be this pesky little bit of code to pull parameters out of a message and pass them to a routine.

There's usually a function lying around in some module that does what you want, but is (and properly so) independent of the "control" layer that invokes it. Such a routine probably takes a couple of parameters. When the system is controlled by messages, those messages generally convey the same information, maybe in more generic units or more abstract format.

    case
        {
        MsgA* msgA = (MsgA*)msg;

        SomeRoutine (msgA->a, msgA->b);
        break;
        }

    if ()
        {
        OneLinerCall();
        }
    else

    if ()
        {
        {
        // OneLiner was really a macro
        };
        }
    else

"For the purposes of debugging, you should take your macro 'calls' and replace them with the individual construct. That is, put the defined do{}while(0); in the main code and try to compile it rather than using the macros."

No, don't do that!
You stand far more chance of messing it up in the process - or even inadvertently fixing a bug!

Anyway, it's a waste of time - the preprocessor does all this for you anyway:
Just use the .i file generated by the preprocessor, and inspect that.
If you can't see the problem by inspection of the .i file, then just compile the .i file!

See Andy's Handy Hint for Debugging Preprocessor Problems:

http://www.8052.com/forum/read.phtml?id=29152

"Just use the .i file generated by the preprocessor, and inspect that."

Some compilers have the option to retain comments in the .i file - which makes the inspection a whole lot easier.

Unfortunately, Keil C51 does not have this option. :-(

Unfortunately, Keil C51 does not have this option. :-(

But even so, you can have this cake and eat it, too. Just use a separate preprocessor (e.g. GCC's) with the right set of options that will let it mimic Keils' #include search mechanisms and predefined macros, instead of Keil itself.