Question

What is wrong with my code? I've been scratching my head over this for hours:

source: http://ideone.com/ffdpr
after applying macro: http://ideone.com/SZUr8

Answer 1

SOLVED: the while loop condition wasn't closed :-P

Answer 2

May be a silly question, but why use the loop in the first place?

Also, while a macro could be a good choice for this, remember that you won't be able to run this through the debugger in a meaningful way. Using a function (which is likely to be inlined) might be better ;)

Answer 3

when i saw do { ... } while (0) construct in other people's code, I also thought it was useless :-P then they showed me what happens if you dont enclose the macro in a block in somethin like:

if (cond) DO_MY_MACRO;

without the do while, since the if statement doesn't use curly braces to close the macro, only the first statement in the macro will run

Answer 4

Ah, yes. Another way to do this is to define the macro with a scoped block:
#define MACRO(a) { dosomething(a); }
Of course that won't work if you want to put a semicolon after the instantiation of the macro. The do/while construct is a valid solution, but I feel it's a bit of a crutch to get around an inherent limitation of macros. Of course if you absolutely want to use a macro for this and be consistent style-wise in terminating macros with ; there's not much choice you have ;)

Alternately, just use an inline function. Macros are good to define values (and even there they're questionable, because they have no symbolic name and hence will always only show up as numeric values in the debugger!) and expressions (such as float compares) that you want to put inline into statements, for example

#define FEQUAL(a,b) (fabsf(a-b)<0.01)

if( FEQUAL(val1, val2) || FEQUAL(val2, val3) )

This only works well for the most simplistic cases like the one above, because debugability also suffers - consider that you'll never be able to step 'into' the macro in the debugger to see what it's doing in case something goes wrong. This can cause big problems especially when macros contain multi-line complex code.
The best case one can make for macros is for compile-time exclusion like

#define USE_EXPERIMENTAL_CODE

#ifdef USE_EXPERIMENTAL_CODE
[insert experimental code here]
#else
[insert tried & true code here]
#endif

This is great to be able to switch behaviors by commenting/uncommenting a single line of code. Another case would be to create an alias for code you want to turn off. For example, consider a simple log function that prints a line of text:

void Log(char *pText)
{
printf("%s", pText);
}

#define LOG(a) Log(a);

Why would you do that? Because now you can automatically remove all logging from the code at compile time in release builds by doing this:

#ifdef DEBUG
#define LOG(a) Log(a);
#else
#define LOG(a)
#endif

It's too simple an example, because you could also simply #ifdef DEBUG the code inside the Log function, but with more complex code that might not be possible. You get the idea.

Those three are just examples for use of macros I'd consider sustainable. Of course, generalization is always problematic (:P) but in most cases except maybe the ones shown in the examples above, I'd recommend a function or function template over a macro. They can be debugged properly, are normally inlined when appropriate, and generally make for nicer code once you've got them written.

Answer 5

Oh, and did I mention macros aren't type safe? Larry the type safe monkey says: be type safe. ;)