Unnecessary parentheses (Was: Help: VAX C problem)
Stan Brown
browns at iccgcc.decnet.ab.com
Sat Apr 20 05:41:01 AEST 1991
In article <3176 at oucsace.cs.OHIOU.EDU>, sadkins at oucsace.cs.OHIOU.EDU (Scott W. Adkins) writes:
> When I learned C, I was taught that parens were unecessary, but it was
> highly recommended to use them for the same reason parens were to be used
> with macros (i.e. #define). I have used them ever since and have grown
> quite attached to them. Anymore, the program just would not look right
> if I leave the parens out. Oh well :-)
I'm afraid I don't see the analogy.
You use parens around an expression in a macro because you don't know
the context of the invocation of the macro. The expression in the
return statement has no such problem.
>>Another place I tend to see unnecessary parens is with the sizeof
>>operator. You can use "sizeof (typename)" or "sizeof expression"...
>>I often see "sizeof (expression)"...usually there's no space between
>>the sizeof and the left paren, which may reinforce the belief that
>>the parens "belong to" the sizeof operator.
> Let us clarify the sizeof operator/function a little bit more. I cannot
> say that this is strictly K&R, because I can't. I do not have access to
> such manuals (or am too lazy to find out I have access to them).
I wouldn't boast of this last if I were you.
> In many
> of the C books, particulary Microsoft, they make a distinction between
> the sizeof operator and the sizeof function.
You don't specify _which_ Microsoft, but this statement is false for
both Microsoft C 5.0 and Microsoft C 5.1, and I'm willing to bet it's
false for any other version.
There is no sizeof 'function'. sizeof is an operator, pure and simple.
As are other C operators, it is overloaded: its operand can be an object
(or any other expression), or a type-cast (which is what the Microsoft C
user's guide, v5.0, calls a type specifier in parentheses).
Section 3.3.3.4 of the standard says, in part, "The sizeof operator
yields the size (in bytes) of its operand, which may be an expression
or the parenthesized name of a type."
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA +1 216 371 0043
email (until 91/4/30): browns at iccgcc.decnet.ab.com
My opinions are mine: I don't speak for any other person or company.
More information about the Comp.lang.c
mailing list