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. The auto-supplied arguments (FILE, LINE, etc. and the plain text of "cond" are not considered for in the format string. So the statement will be somewhat more complex, and of course take care of sending the resulting string on its way. I like the idea. Thanks. I'll think about that some more. —John

On Thu, 9 Feb 2012, 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.

Here's a variant that might work better for that: #define MY_FANCY_ASSERT(cond, str) \ for (bool BOOST_PP_CAT(assertcond, __LINE__) = (cond); \ BOOST_PP_CAT(assertcond, __LINE__); \ BOOST_PP_CAT(assertcond, __LINE__) = false) \ format(str) % __FILE__ % __LINE__ -- Jeremiah Willcock

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@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On 2/10/2012 1:46 PM, Michael Schulze wrote:

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.

How is that different from leaving off the do and while and just putting braces around the whole thing?

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

on Thu Feb 09 2012, 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)

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

On Thu, Feb 9, 2012 at 11:05 PM, John M. Dlugosz wrote:

On 2/9/2012 1:49 PM, Nat Linden wrote:

...

template <typename FUNCTOR> void ourmacro_f(const FUNCTOR& f) {     f(hidden_ostream_object); }

#define OURMACRO(EXPRESSION) (ourmacro_f(boost::lambda::_1 << EXPRESSION))

How is that different from just using:

       #define OURMACRO(EXPRESSION) hidden_stream_object << EXPRESSION

Simply that hidden_stream_object really isn't visible in the calling context. It's local to the context of ourmacro_f().

On Sat, Feb 11, 2012 at 2:23 AM, John M. Dlugosz wrote: On 2/10/2012 7:35 AM, Nat Linden wrote:

...

On Thu, Feb 9, 2012 at 11:05 PM, John M. Dlugosz wrote:

On 2/9/2012 1:49 PM, Nat Linden wrote:

...

template<typename FUNCTOR>

...

...

void ourmacro_f(const FUNCTOR& f) { f(hidden_ostream_object); }

#define OURMACRO(EXPRESSION) (ourmacro_f(boost::lambda::_1<**< EXPRESSION))

How is that different from just using:

...

#define OURMACRO(EXPRESSION) hidden_stream_object<< EXPRESSION

Simply that hidden_stream_object really isn't visible in the calling context. It's local to the context of ourmacro_f().

Sorry, I'm still not seeing the point. The name hidden_stream_object is not in scope here but ourmacro_f is instead? So what?

Or, a plain function to return the stream object?

ostream& get_stream() { return hidden_stream_object; }

#define OURMACRO(EXPRESSION) get_stream()<< EXPRESSION

Okay, so I've oversimplified the example code. The point is that the boost::lambda::_1 placeholder defers the evaluation, giving you extra control over the operation. Put differently, the expression is evaluated in the context of your function rather than in the calling context. Consider: template<typename FUNCTOR> void ourmacro_f(const FUNCTOR& f) { if (some_condition) { f(hidden_ostream_object); } } or how about: template<typename FUNCTOR> void ourmacro_f(const char* expr_string, const FUNCTOR& f) { try { f(hidden_ostream_object); } catch (const std::exception& e) { hidden_ostream_object << "Exception " << typeid(e).name() << " evaluating (" << expr_string << "): " << e.what() << std::endl; } } #define OURMACRO(EXPRESSION) (ourmacro_f(#EXPRESSION, boost::lambda::_1 << EXPRESSION))