sizeof

[ena8t8si]

Richard posted:



If "x" is a type, then the parentheses are mandatory:

int i = sizeof(int); /* OK */

int i = sizeof int; /* Compile Error */

If "x" is an expression, then "sizeof" works just like any other unary
operator:

Not like _any_ other unary operator:

- (int) - 3 == - ((int) -3)

but

sizeof (int) - 3 == (sizeof (int)) - 3

 

[J. J. Farrell]

Could someone point me to why "sizeof x" is/isnt preferable to "sizeof(x)",

For exactly the same reason that "x = y" is preferable to "x = (y)".

 

[J. J. Farrell]

I include them wherever possibe.

No you don't (at least, not unless every source file you create is
within one source character of the maximum size supported by your
compiler).

So at the end of the day "sizeof x" and "sizeof(x)" are identical?

Unless x is a type, the second includes distracting and unnecessary
parenthesis.

 

[J. J. Farrell]

its not "conceptually" the same in my view.

You appear to have a strange view. Could you explain why it's not the
same?

It makees sense to me to type it so:

x += sizeof(y);

maybe its because i'm getting old and am just more used to it.

I certainly wouldnt write any code of the form

x = (a) + (b);

Why the lack of consistency?

And am still at a bit of a loss as to whyt Richard mentioned it when I
was asking if there are any differences between the two styles.

'sizeof', '+', and '=' are all operators. Why use different styles for
the expression being operated on? Consistency of style helps make code
more readable. If it makes sense to you to put a parenthesis around the
expression being operated on by 'sizeof', why would you certainly not
put one round the same expression when it's being operated on by '+' or
'='?

Come to that, why not put a few more in, as in 'sizeof((((x))))'?

 

[Default User]

I guess at the end of the day I "see" sizeof as a function -
regardless of the fact it isnt.

Some people like to put the expression in a return statement in
parentheses as well, and usually for similar reasons. It still muddles
the code for no particularly good reason (as a general practice).

Traditionally all C code Ive ever worked on has always used
parenthesis in its use : it seems more natural to me. And now I know
there is no difference in the two styles I'll stick with it I think.
Frankly I think

x=x+sizeof q - 3

is horrible and confusing.

So rearrange it.

x = x - 3 + sizeof q;



Brian

 

[Keith Thompson]

Could someone point me to why "sizeof x" is/isnt preferable to "sizeof(x)",

Given that x is an expression (say, the name of an object), I prefer
"sizeof x" to "sizeof(x)" for the same reason that I prefer "return x;"
to "return(x);".

The parentheses make both "sizeof(x)" and "return(x);" look like
function calls, which they're not. Treating sizeof as a unary
operator emphasizes the fact that it's not a function, and more
importantly, it doesn't *act* like a function. The argument to sizeof
(assuming there are no VLAs involved) is not evaluated, and the result
doesn't depend on the value of the expression, only on its type. No
function behaves like that.

The temptation to write sizeof(x), I think, comes from two sources.
One, sizeof(type) does require parentheses, and it looks (too much,
IMHO) like a function call. If you always use parentheses, you don't
have to remember the rule, and it always works. The other is that
sizeof is the only operator specified by a keyword (which looks like
an identifier) rather than by a symbol. If the operator were
specified by, say, a "$" symbol, there'd be no temptation to write
"$(x)" rather than "$ x", any more than you'd write "!(x)", or "-(x)",
or "~(x)". (Some languages have a number of operators represented by
keywords; others use symbols for everything. I think C is unusual in
having just one keyword operator.)

Having said that, I don't strongly object to the unnecessary
parentheses in "sizeof(x)". I don't use them myself, because omitting
them demonstrates and reinforces a deeper understanding of what's
really going on, but I can certainly deal with them in code that I
read. And nobody reading C code should actually be *fooled* by
"sizeof(x)" into thinking that it's a function call.

I find the unnecessary parentheses "sizeof(x)" a bit less annoying
than the ones in "return(x);" (for no good reason I can think of).

 

[Keith Thompson]

I guess at the end of the day I "see" sizeof as a function - regardless
of the fact it isnt.

Traditionally all C code Ive ever worked on has always used parenthesis
in its use : it seems more natural to me. And now I know there is no
difference in the two styles I'll stick with it I think. Frankly I think

x=x+sizeof q - 3

is horrible and confusing.

In that particular case, there's an operator precedence issue. If
binary "-" bound more tightly than unary "sizeof", this could mean
x = x + sizeof(q - 3)
and of course if you really *wanted* sizeof to apply to "q - 3", you'd
need the parentheses.

Then again, writing it as
x = x + sizeof(q) - 3
doesn't change anything; if "-" bound more tightly, that would still mean
x = x + sizeof((q) - 3)

If you have trouble interpreting the expression, *and* you know that
sizeof is an operator, you can write it as:
x = x + (sizeof q) - 3

 

[Frederick Gotham]

Keith Thompson posted:

If you have trouble interpreting the expression, *and* you know that
sizeof is an operator, you can write it as:
x = x + (sizeof q) - 3

I'd quicker tell them to wean themselves off parentheses, and start studying
their operator table of associativity and precedence.

If I'm unsure, I don't use parentheses, but rather I whip out my operator
table.

 

[Frederick Gotham]

Keith Thompson posted:

I find the unnecessary parentheses "sizeof(x)" a bit less annoying
than the ones in "return(x);" (for no good reason I can think of).

Simply because it's so common place. I'd dare say I even think:

sizeof(expr)

is more prevalent than:

sizeof expr

(And the situation's the same in C++ too.)

You get conditioned to dislikeable things if you encounter them more often
-- it's not that they become less dislikeable, but rather that you stop
dwelling on your disliking.

For an emergency room doctor, it would be LESS dislikeable for them to see
a mangled corpse every day, than it would be to see one once every six
months -- the more frequently they encounter it, the more conditioned they
become.

The following:

return(5);

is far less common than:

return 5;

And so it's less easy to not dwell on our disliking of it.

I myself quite dislike the use of "same line opening brace" for functions,
e.g.:

void Func(void) {

}

But the more I see it, the less I care.

 

[Keith Thompson]

Keith Thompson posted:

I'd quicker tell them to wean themselves off parentheses, and start studying
their operator table of associativity and precedence.

If I'm unsure, I don't use parentheses, but rather I whip out my operator
table.

If you're unsure, it's likely that anyone reading your code will also
be unsure, and you force them to waste time whipping out their own
operator tables.

I tend to go fairly light on parentheses myself, but I don't hesitate
to use them, even if they're not required, if they make the code
clearer.

 

[Frederick Gotham]

Keith Thompson posted:

If you're unsure, it's likely that anyone reading your code will also
be unsure, and you force them to waste time whipping out their own
operator tables.

Yes, I realise that. In similar vein: If I'm ever lucky enough to have
children one day, I'll show them how to tie their own shoe-laces, rather than
tie them for them. I think it's good to breed independance.

I tend to go fairly light on parentheses myself, but I don't hesitate
to use them, even if they're not required, if they make the code
clearer.

I prefer the "Look at me... I know the operator table off by heart!"
attitude.

: )

 

[Dik T. Winter]

>
> Some people like to put the expression in a return statement in
> parentheses as well, and usually for similar reasons. It still muddles
> the code for no particularly good reason (as a general practice).

I do not know whether it muddles the code. Needless parenthesis can
also clarify the code. I write sometimes additional parenthesis in
expressions, so that not anybody who reads the code has to know the
precedence tables completely from memory to know what is happening.

 

[Dik T. Winter]

> The parentheses make both "sizeof(x)" and "return(x);" look like
> function calls, which they're not. Treating sizeof as a unary
> operator emphasizes the fact that it's not a function, and more
> importantly, it doesn't *act* like a function. The argument to sizeof
> (assuming there are no VLAs involved) is not evaluated, and the result
> doesn't depend on the value of the expression, only on its type. No
> function behaves like that.

No other operator behaves like that either. So, this is in my
opinion a bogus argument.

 

[Keith Thompson]

No other operator behaves like that either. So, this is in my
opinion a bogus argument.

Ok, that's a fair point (though "." and "->" are also described as
operators, and they behave oddly too, though in different ways.)

The point is that operators are built into the language, and there's
more freedom to define them to behave in odd ways than there is for
functions. IMHO using unnecessary parentheses around the operand to
sizeof obscures the fact that it's something built into the language
-- and it's something that probably wouldn't occur to anyone if it
were defined as a punctuation symbol rather than a keyword/identifier.

There's no more (or less) reason to parenthesize an expression that's
an operand of "sizeof" than to do so for an operand of "!" or "~".

 

[Hallvard B Furuseth]

I find the unnecessary parentheses "sizeof(x)" a bit less annoying
than the ones in "return(x);" (for no good reason I can think of).

Expression vs. statement, maybe. And it _looks_ consistent that way:
return x; without () resembles return; and goto y;
sizeof(x) resembles other kinds of expression_dependent_of(x).
Doesn't resemble other operators, but other operators don't consist of
letters anyway.

I use return x; but sizeof(y). Haven't thought much about why before.
(Yes, sizeof(y) also resembles a function call which evaluates y, but
then so do macros.)

 

[Mikhail Teterin]

I find the unnecessary parentheses "sizeof(x)" a bit less annoying

Don't you _have to_ use them, when you wish for something like sizeof(x)*n?
I suppose, you could do (sizeof x)*n, though -- not sure, which is better...

than the ones in "return(x);" (for no good reason I can think of).

One good reason is the ability to quickly do something like:

#define return(A) fprintf(stderr, "%s: returning %d\n", __func__, A);

I believe, this is why BSD's C-style manual requires the parens...

http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9

Yours,

-mi

 

[Frederick Gotham]

Mikhail Teterin posted:

Don't you _have to_ use them, when you wish for something like
sizeof(x)*n?

No.

"sizeof" has the same precedence as dereference. Multiplication has lower
precedence.

sizeof x * n

is equivalent to:

sizeof(x) * n

is equivalent to:

(sizeof x) * n

 

[Joe Wright]

Expression vs. statement, maybe. And it _looks_ consistent that way:
return x; without () resembles return; and goto y;
sizeof(x) resembles other kinds of expression_dependent_of(x).
Doesn't resemble other operators, but other operators don't consist of
letters anyway.

I use return x; but sizeof(y). Haven't thought much about why before.
(Yes, sizeof(y) also resembles a function call which evaluates y, but
then so do macros.)

How many messages in this thread?

Assuming y an expression, 'sizeof y' is correct. sizeof(y) is to be
shunned. It makes sizeof look like a function. It is not.

Assuming T a type, 'sizeof (T)' is to be preferred over 'sizeof(T)'
which looks like a function. 'sizeof T' is an error of course.

So do macros what?

 

[Keith Thompson]

Don't you _have to_ use them, when you wish for something like sizeof(x)*n?
I suppose, you could do (sizeof x)*n, though -- not sure, which is better...


One good reason is the ability to quickly do something like:

#define return(A) fprintf(stderr, "%s: returning %d\n", __func__, A);

I believe, this is why BSD's C-style manual requires the parens...

http://www.freebsd.org/cgi/man.cgi?query=style&sektion=9

I took a *very* quick look at that web page, and I saw several style
rules that I really dislike. I would follow those requirements if
*and only if* I were working on FreeBSD kernel sources.

Note that "#define return(A)" kludge works only for functions that
happen to return int -- and I don't see any mention of it in the style
manual. My guess is that the rule exists just for consistency; you
can use parentheses on a return statement or not, and they decided to
use them. Consistently using "return (expr);" is better than randomly
using one form or the other.

There are plenty of style manuals floating around. I don't think
you'll find that the FreeBSD one carries any particular weight here.

 

[Andrew Poelstra]

So rearrange it.

x = x - 3 + sizeof q;

x += (sizeof q) - 3;

would be an appropriate use of parentheses in this situation, IMHO, and
would likely be the form I'd use. (I very rarely use sizeof outside of
malloc and friends, though.)