Clearly, there are times where #define statements must have parentheses, like so:
#define WIDTH 80+20
int a = WIDTH * 2; // expect a==200 but a==120
So I always parenthesize, even when it's just a single number:
#define WIDTH (100)
Someone new to C asked me why I do this, so I tried to find an edge case where the absence of parentheses on a single number #define causes issues, but I can't think of one.
Does such a case exist?
Yes. The preprocessor concatenation operator (##) will cause issues, for example:
#define _add_penguin(a) penguin ## a
#define add_penguin(a) _add_penguin(a)
#define WIDTH (100)
#define HEIGHT 200
add_penguin(HEIGHT) // expands to penguin200
add_penguin(WIDTH) // error, cannot concatenate penguin and (100)
Same for stringization (#). Clearly this is a corner case and probably doesn't matter considering how WIDTH will presumably be used. Still, it is something to keep in mind about the preprocessor.
(The reason why adding the second penguin fails is a subtle detail of the preprocessing rules in C99 - iirc it fails because concatenating to two non-placeholder preprocessing tokens must always result in a single preprocessing token - but this is irrelevant, even if the concatenation was allowed it would still give a different result than the unbracketed #define!).
All other responses are correct only insofar that it doesn't matter from the point of view of the C++ scanner because, indeed, a number is atomic. However, to my reading of the question there is no sign that only cases with no further preprocessor expansion should be considered, so the other responses are, even though I totally agree with the advice contained therein, wrong.
Sometimes you have to write code not with the current caveats in mind, but with the caveats of the next time it is going to be edited.
Right now your macro is a single integer. Imagine someone editing it in the future. Let's say they are not you, but someone who is less careful or in more of a hurry. The parenthesis is there to remind them to put any modifications in parenthesis.
This kind of thinking is a good habit in C. I personally write code in a style which some people might find "redundant", with things like this but especially with regards to error handling. The redundancy is for maintainability and composability of future edits.
Whenever the define consists of a single token (one operand only, no operators), the parentheses are not needed because a single token (such as 100) is an indivisible atom when lexing and parsing.
As Blagovest Buyukliev said:
The define consists of a single token (one operand only, no operators), the parentheses are not needed because a single token (such as 100) is an indivisible atom when lexing and parsing.
But I would recommend the following rules when it comes to macros:
- Avoid function like macros @see Lundin's comment.
If you want to use function like macros badly consider the following 2 rules:
- Always use brackets for arguments in macros
- Only use an macro argument once
Why rule 1.? (To keep the order of the operations correct)
#define quad(x) (x*x)
int a = quad(2+3);
will expand to:
int a = (2+3*2+3);
Why rule 2.? (To ensure a side effect is only applied once)
#define quad(x) (x*x)
int i = 1;
int a = quad(i++);
will expand to:
int a = i++ * i++;
Since 100 is a single token, I doubt you'll find a corner case where the parentheses matter (for a single token!)
It's still a good habit IMO, since they can matter when there are multiple tokens involved.
No. There is no case where #define WIDTH 100 can yield an unambiguous or "surprising" expansion. That's because it can only result in a single token being replaced by a single token.
As you know, macro confusion ensues when a single token (e.g. WIDTH) results in multiple tokens (e.g. 80 + 20). As far as I can surmise, that's the only cause for the use of parentheses in substitutions and, as explored in my first paragraph, it doesn't apply here.
However, this technical fact aside, it may still be a good practice. It promotes habit, and it also serves as a reminder if that macro ever gets modified to something more complex.
There's a good reason, sometimes.
For a single number, there's no good reason.
For other cases, as you have shown yourself, there is a good reason.
Some people prefer to be extra careful, and always use the parentheses (@aix recommends it. I don't, but there's no hard answer).
When code defines only a number, @Alexander Gessler well answers the question.
Yet many coders do not notice the unary operators in the following:
#define TEMPERATURE1M (-1)
#define TEMPERATURE1P (+1)
When code uses a #define that employs an operator, enclosing () insures expected numeric results and precedence.
#define TEMPERATURE_WITH (-1)
#define TEMPERATURE_WITHOUT -1
// Consider how these will compile
int w = 10-TEMPERATURE_WITH;
int wo = 10-TEMPERATURE_WITHOUT; // May not compile
The last line of code may compile given C99 semantic changes @Olaf
It certainly won't hurt and it is a good habit. But there is no difference between (100) and 100 for numerical calculations.
来源：https://stackoverflow.com/questions/9081479/is-there-a-good-reason-for-always-enclosing-a-define-in-parentheses-in-c