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

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
participants (1)
-
Dave Gomboc