on Thu Feb 09 2012, Kim Barrett
On Feb 9, 2012, at 1:47 AM, John M. Dlugosz wrote:
On 2/9/2012 12:21 AM, Jeremiah Willcock wrote:
Would it be reasonable for your use case to have MY_FANCY_ASSERT be:
#define MY_FANCY_ASSERT(cond, str) \ if (cond) {} else format(str) % __FILE__ % __LINE__
or similar? It would restrict where you could use it, but would be simple and guarantee the properties you want.
Actually, that's not at all too unreasonable. I had shied away from making a macro that "eats" the following arguments in a non-expression way, on general principles. But I see that what you have doesn't leave a dangling-else problem, and I suppose people won't notice that it's at all funny.
I have a similar macro and just yesterday received a bug report from one of my users because code like this
if (cond1) MY_FANCY_ASSERT(cond2, ...) ... ;
was resulting in compiler warnings from gcc: -Wparentheses (enabled by -Wall) complains about potential confusion over which "if" an "else" belongs to. I was unable to find a way to suppress the warning locally to the macro, even with the local diagnostic control pragmas available in gcc4.6 (though it might be argued that some of what I was seeing should be considered gcc bugs (I intend to file a bug report)
Any old-timey C programmer will tell you the trick is to put your code inside a do { ... } while(0): #define MY_FANCY_ASSERT(cond, str) do { \ if (cond) {} else format(str) % __FILE__ % __LINE__ \ } while(0) Cheers, -- Dave Abrahams BoostPro Computing http://www.boostpro.com