Bob Paddock wrote:
This reference says the same, as I would have answered without reading it now: It is sensible, to put parentheses around parameters in a macro definition likeParentheses around a constant are nonsense - there is nothing a plain number could evaluate to in the preprocessor than itself (unless you "#define 1e20 (foo * i++)"), so it has the highest precedence by itself. (couldn't you even "#define (1e20) foo*i++" ?;-)Not knowing how the #define could be used in all cases it is better to put parentheses around such usages to have the compiler generate an error, rather than silently give the wrong value in corner cases where operators like multiplication and division are passed as parameters to an other macro. http://gimpel-online.com/MsgRef.html Look up #665. MISRA2004 19.4 and 19.10 apply in some circumstances as well.
#define MY_MULT(a, b) do {(a) * (b)} while (0)
because someone could call it like MY_MULT(x+y, u+v), that would evaluate
to x + y*u +v otherwise. But a constant definition like
#define FOREVER 1e20
doesn't have any macro parameters. Therefore defining it like
#define FOREVER (1e20)
is pointless. The parentheses just get ignored by the compiler, so they
don't hurt either. They just show that the programmer doesn't know
in this case, why he is doing what. Not to be confused with
#define FOO_BIT 0x0001
#define BAR_BIT (FOO_BIT << 1)
#define BUZ_BIT (BAR_BIT << 1)
where a computation is involved, that could get broken by context.
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user