Re: [Boost-users] Metaprogramming Question

Subject: Re: [Boost-users] Metaprogramming Question
From: Michael Schulze (mschulze_at_[hidden])
Date: 2012-02-10 14:46:33

On 02/09/2012 10:29 PM, Kim Barrett wrote:
> 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.
That is not a bug of gcc. It is right if it states that the
interpretation could be done in two way either the else belongs to the
first if or to the second one. However, you can make yourself and the
compiler happy. Try the following.

#define MY_FANCY_ASSERT(cond, str) \
   do { if (cond) {} else format(str) % __FILE__ % __LINE__ } while(0)

With this you have encapsulated the if-else statement and the compiler
has now no reasons to complain anymore.

-- Michael

> 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.
> 
> _______________________________________________ Boost-users mailing
> list Boost-users_at_[hidden] 
> http://lists.boost.org/mailman/listinfo.cgi/boost-users