Re: [Boost-users] Metaprogramming Question

Subject: Re: [Boost-users] Metaprogramming Question
From: Kim Barrett (kab.conundrums_at_[hidden])
Date: 2012-02-09 16:29:37

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),
so it might be that some future version of gcc will provide sufficient
warning control for this situation).  The workarounds are, of course,
to move cond1 into the macro's conditional or to put braces around the
whole outer "then" statement.

Note that in nearly 3 years of heavy use of our facility that uses
this idiom, this is the first time this issue has come up.  So I
wouldn't let this annoying warning stop you from taking this approach,
just be warned (no pun intended) that there is this minor issue.