http://msdn.microsoft.com/en-us/library/d9x1s805.aspx

Details how it works, and it does work, successfully, on both VS2005 and VS2008. I didn’t care so much about other compilers than MSVC and gcc for this experiment, but since gcc doesn’t have an equivalent warning, it didn’t matter for me.

I’m not sure why “while (true, false)” wouldn’t trigger it, but I wouldn’t be surprised to see it start issuing a warning as compilers get better…

instead of…
do { } while (FALSE)

…I defined a global constant and modified the macro to…
do { } while (myAlwaysFalseConstant)

This doesn’t produce a warning (at least not in the environments I’ve tested: Visual Studio 2008 and TI’s Code Composer 3.3 for the 320C6400 DSP family) and doesn’t rely on undocumented compiler behavior. It does produce slightly more code than do { } while (FALSE), but very marginally so.

For me, wishing to support both a Visual Studio environment for off-line testing and a DSP environment for target code, the do { } while (__LINE__ == -1) alternative is not an option.

Of course, some people dislike globals as a matter of principle. When you tell me the idea is no good, I shall expect a better reason than that

[code]
#define UNUSED(var) (var)
[/code]

to:

[code]
//**********************************************************
// Nifty little helper macros that are used *everywhere*
//**********************************************************
#define UNUSED(var) MACRO_BEGIN \
(void)sizeof(var); \
MACRO_END
#define UNUSED_VARIABLE(var) UNUSED(var)
#define UNUSED_PARAMETER(prm) UNUSED(prm)
[/code]

Now, I have tried virtually every alternative presented within this article and related comments except for the try/catch above to accomplish 3 things:

1) Avoid the C4127 warning,
2) Remove/reduce the required assembly code to shut-up the compiler, and;
3) if possible, remove compiler dependancy from the code (ie: Microsoft VC++)

Here’s what I found out…

[code]
#define MACRO_END } while(__LINE__ == -1)
[/code]

still gives me the C4127 warning – I am running VC++ 2008 w/sp1 – So I will continue to test other alternatives…

[code]
inline bool False(void) {return false; }
#define MACRO_BEGIN do {
#define MACRO_END } while(False())
[/code]

My first thoughts were that this would “optimize out” the *call* to False() and replace it with a simple MOV EAX, 0 – but this didn’t happen. Instead, I got the following generated assembly code…

[code]
$LN3@Update:

; 494 : UNUSED_PARAMETER(elapsed_time);

01297 e8 00 00 00 00 call ?False@TOOLBOX@@YA_NXZ ; TOOLBOX::False
0129c 0f b6 c0 movzx eax, al
0129f 85 c0 test eax, eax
012a1 75 f4 jne SHORT $LN3@Update

[/code]

Notice the call to False() is still there. Of course, it’s immediately followed by the mov instruction I was expecting (a variant anyway). I noticed that the move was dealing with al (1-byte) – duh… type bool is 1-byte so this makes sense… I then replaced the False() function with the following definition…

[code]
inline int False(void) { return 0; }
[/code]

and this time the generated code looks like:

[code]
$LN3@Update:

; 494 : UNUSED_PARAMETER(elapsed_time);

01297 e8 00 00 00 00 call ?False@TOOLBOX@@YAHXZ ; TOOLBOX::False
0129c 85 c0 test eax, eax
0129e 75 f7 jne SHORT $LN3@Update
[/code]

Better, but notice the call to False() is still there… Maybe that has something to do with my compiler settings, but I don’t want to have to “tweak” the compiler for this one macro / function…

So, I moved on to the next alternative…

[code]
#define MACRO_END \
__pragma(warning(push)) \
__pragma(warning(disable:4127)) \
} while(0) \
__pragma(warning(pop))
[/code]

This doesn’t even compile. I get “error C2017: illegal escape sequence” and related messages… In addition, __pragma() is Microsoft specific. I really don’t like this alternative anyway so on to the next…

[code]
#define MACRO_END } while(true,false)
[/code]

Now this is promising… This version generates the following assembly code and as far as I know, is not compiler dependant nor does it generate a C4127 warning…

[code]
$LN3@Update:

; 494 : UNUSED_PARAMETER(elapsed_time);

01297 33 c0 xor eax, eax
01299 75 fc jne SHORT $LN3@Update
[/code]

So, as a test, I set the MACRO_END definition back to the original:

[code]
#define MACRO_END } while(0)
[/code]

and accepting the C4127 warning, I wanted to see the generated code and with this I get the following assembly output:

[code]
$LN3@Update:

; 494 : UNUSED_PARAMETER(elapsed_time);

01297 33 c0 xor eax, eax
01299 75 fc jne SHORT $LN3@Update
[/code]

Which is identical to the version immediately above…

Therefore, it seems to me that the method of defining MACRO_END as:

[code]
#define MACRO_END } while(true,false)
[/code]

satisfies my requirements. So in conclusion, I will be sticking to the while (true,false) variety as proposed by Phill Djonov above. Thanks Phill!

NOTE: All of the above generated code was for x86 in RELEASE build. I have no idea of the generated Itanium or what-not processor’s code. Ideally, I’d like to remove the xor and jne instructions too, however, they appear to be a by-product of the do..while() loop. As arguments for their inclusion seems to be reasonable, I guess I will continue with this approach. Anyone know of a way to eliminate those?

Jumpster

I disagree with the comment about destructors. You can use try catch in destructors, the only thing that is calling for problems is throwing exceptions outside destructors. Even more, you **should** catch every exceptions possibly thrown by functions called in a destructor or it will go outside and **then** you will have problems…

#define MULTI() { std::printf(“Hello”); std::printf(” world!\n”); }

fails when you do this:

if (a)
MULTI();
else
MULTI();

The semicolons create syntax errors.

[WORDPRESS HASHCASH] The poster sent us ’0 which is not a hashcash value.

# #define MULTI_LINE_MACRO \
{ \
std::printf(“Hello “); \
std::printf(“world!\n”); \
}

?

Not that I like the do {} while(false) trick any better, mind you.

#define MULTI_LINE_MACRO \
try { \
std::printf(“Hello “); \
std::printf(“world!\n”); \
} catch (…) { throw; }\