Re: [boost] Macros at namespace scope: trailing semicolon?

From: Dave Gomboc (dave_at_[hidden])
Date: 2005-07-18 12:27:22

You were asking another, but...

> 1)  Do you think that the LOG() macro should contain a trailing
>     semicolon?

The macro itself should, yes, so the user need not type one.
 

> 2) I'm pretty sure you'll say #1, but which of the following
examples
>    do you prefer?
> 
>    int foo()
>    {
>      LOG("NO SEMICOLON HERE?")          // 1
>      stuff();
> 
>      LOG("OR does this seem better?");  // 2
>      more_stuff();
>    }

#1.  If someone did #2, yielding an extra, empty statement, it's not
a tragedy, however (unless my compiler warned about such empty
statements -- in which case I would delete the extraneous
semicolon.)  There's undoubtedly some compiler that boost supports
that will do this, so best not to have the extra one there in the
first place, I think.

> 3) Do you see harm if the macro does not contain the trailing
>     semicolon?  If so, what harm is it?  Specifically, how does
usage
>     #2 above re-enforce bad understanding of macros?  (Or am I
>     misconstruing the nature of your objection?)

It's logically inconsistent for the macro to not to perform its
entire job.  If that job is to "expand into an expression",
certainly, it shouldn't generate a semicolon.  If that job is to
"expand into a statement", then just as certainly, it should.  But
its job ought not to be to "expand into a statement except for the
trailing semicolon": that would be absurd.

> 4) What is the important degree of indirection that I would be
missing
>    by talking about the usage of the LOG macro as a call to the
log
>    function?  I understand that I could call it "a macro that
expands
>    to a call to the log function" but I don't think that anyone
would
>    be more enlightened by that.  Other than being more detailed
about
>    what's really happening, it's not clear to me what important
>    mistake is being made that bothers you.  If our coding
convention
>    states that macros are uppercase, then we already know it's a
>    macro, so simply repeating that is unnecessary, IMHO.

Referring to it as the log function is clearly wrong.  The listener
might doubt your understanding, even if you knew perfectly well that
it was indeed a macro that expanded to a function call.

I see no disadvantage in referring to it as the LOG macro.

Dave