sizeof() style question

  • Thread starter Christopher C. Stacy
  • Start date
T

Tim Rentsch

Keith Thompson said:
I expect it's just a coincidence. Parentheses are used for enough
different things that it's not surprising a couple of them look alike
when taken out of context.

1. Both are elements of expressional forms;

2. Both have ()'s to prevent undesireable interaction with other parts
of the expression;

3. Both are used to express a "type value";

4. They have identical syntax.

What relevant context would you say is missing?
 
P

pete

Chris said:
Except that it's a compile-time function.

Has everybody gone insane?
But I agree that in a
mathematical sense the result is a function of the (type of the)
parameter.

Parameters are automatic objects.
The operand of sizeof has no such constraint.
The result of any operation,
is a function of the operand or operands.
I don't think that it's really an operator, it doesn't
operate on anything.

"operand of the sizeof operator" means nothing to you?
 
M

Martin Ambuhl

Malcolm said:
I agree. sizeof is a function, so it sould take its argument in parentheses
like other C functions.

Sorry, but sizeof is not a function. It is an operator.
It is a function of the type rather than the value of its argument, so
sizeof(int) is preferable to sizeof(x).

It is not a function at all. It is incorrect to say of that which is
not a function that it is a function of x rather than a function of y.
 
R

Robert W Hand

Except that it's a compile-time function. But I agree that in a
mathematical sense the result is a function of the (type of the)
parameter. I don't think that it's really an operator, it doesn't
operate on anything.

I'm sure that some of the problem in this thread is due to mixing
technical and colloquial uses of some terms. Let's be clear, the
technical term for sizeof in the C Standard is operator - not macro,
not function or not even compile-time function.

The "mathematical sense" of function and operator are muddy to start
with. Much of Linear Algebra explores the relationship between
operators and functions. I would not confuse the issue further, by
introducing "mathematical sense" to this discussion.

Let's try to stick to the term in the C Standard - operator.
 
L

Lawrence Kirby

I agree. sizeof is a function, so it sould take its argument in parentheses
like other C functions.

The key thing to realise is that sizeof CANNOT be a function in C because
C functions cannot take types as arguments, or take type information from
an expression argument. C defines sizeof as a keyword and an operator. As
such it is not bound to function-like syntax. Indeed thinking of it as a
function is an error, because it does not work on the value of its operand.
It is a function of the type
rather than the value of its argument, so
sizeof(int) is preferable to sizeof(x).

In a very theoretical sense you have a small point, but for practical
purposes sizeof x is usually more appropriate than sizeof(int), and C is a
practical language. There are good theory based reasons too, such as
avoiding duplicate definitions of the same information which introduces
risk of consistency errors.
Personally I'm sceptical of the
argument that sizeof *ptr is robust to changes in the type of ptr -
anyone who changes the type of a pointer should scan through all code
that references it as a matter of course. However it is a legitimate
point..

It is certainly robust. There is real risk of missing things if you depend
on scanning code to find them. No risk is the code is correct in the first
place. Also consider that it is easy to get the type wrong in a sizeof e.g.
I've seen plenty of instances of code like

int **ptr;

ptr = malloc(N * sizeof(int));

Writing it like

ptr = malloc(N * sizeof *ptr)

provides a single clear form for most of not all such cases, it is even
uniform enough to be wrapped in a macro such as:

#define MALLOC(ptr, N) ((ptr) = malloc((N) * sizeof *(ptr)))

and which makes usage very simple:

if (MALLOC(ptr, NELEMS) == NULL) {
...
}

Lawrence
 
C

CBFalconer

Chris said:
.... snip ...

IMO, yes. It also ensures that it avoids ambiguity:

malloc(sizeof x * y)

is visually ambiguous, since unlike the ordinary operators the
precedence is not obvious (OK, the precedence of bit operators
is odd as well, so I always fully parenthesise those).

Which is why I always write that as:

malloc(y * sizeof x)
 
M

Malcolm

Robert W Hand said:
I'm sure that some of the problem in this thread is due to mixing
technical and colloquial uses of some terms. Let's be clear, the
technical term for sizeof in the C Standard is operator - not macro,
not function or not even compile-time function.

The "mathematical sense" of function and operator are muddy to start
with. Much of Linear Algebra explores the relationship between
operators and functions. I would not confuse the issue further, by
introducing "mathematical sense" to this discussion.

Let's try to stick to the term in the C Standard - operator.
Virtually every C compiler will incorporate a function (in the C sense,
probably written in C) called something like getsize(), that takes a type as
an argument and returns the number of bytes occupied. It will be a
moderately complicated function because it has to support structures.

Of course this function is evaluated at compile time, so sizeof resolves to
a constant. Most of the other operators cause small numbers of machine
instructions to be executed, unless all their operands happen to be
constants, which programmers want sometimes for clarity eg 2 * PI.

So it's a peculiar operator in three ways; the evaluation is not
mathematically simple, it doesn't cause runtime instructions to be executed,
and the operand is a type not a scalar.

Basically it is a function of a type. We're just teasing by using the word
"function" because the ANSI committee, in its arrogance, has presumed to
define how this word shall be used.
 
K

Keith Thompson

Tim Rentsch said:
1. Both are elements of expressional forms;

2. Both have ()'s to prevent undesireable interaction with other parts
of the expression;

3. Both are used to express a "type value";

4. They have identical syntax.

What relevant context would you say is missing?

I suppose I was thinking of the fact that the parenthesized type name
is followed by an expression in a cast expression, and isn't in
sizeof(type). That, and the fact that sizeof(type) allows any object
type, and a cast only allows certain types (no unions, structs, or
arrays).

I suppose the real question is whether the inventor(s) of the
sizeof(type) form were thinking of casts when they designed the syntax
(I'm not sure whether it originated in C or in one of its
predecessors). I don't know the answer to that.

Note also that there is no single syntactic construct corresponding to
a parenthesized type name. It can only be part of a cast-expression,
or part of a sizeof(type) expression.

Having said all that, I don't think it's a particularly important
question.
 
B

BGreene

Robert W Hand said:
I'm sure that some of the problem in this thread is due to mixing
technical and colloquial uses of some terms. Let's be clear, the
technical term for sizeof in the C Standard is operator - not macro,
not function or not even compile-time function.

The "mathematical sense" of function and operator are muddy to start
with. Much of Linear Algebra explores the relationship between
operators and functions. I would not confuse the issue further, by
introducing "mathematical sense" to this discussion.

Let's try to stick to the term in the C Standard - operator.
--

Best wishes,

Bob

Some of us have forgotten most of our Linear Algebra :).
 
A

Ari Lukumies

Michael said:
type *p;
p = malloc(some_number * sizeof *p);

works for arbitrary type "type", whereas sizeof (type) works
only as long guaranteed as p is a pointer to type.

And your point here is...? sizeof(variable), sizeof(*variable),
sizeof(type) gives the size, no matter what. And (do not take this too
personally), it's better to put in the parenthesis, to diminish confusion.

-atl-
 
K

Keith Thompson

Ari Lukumies said:
And your point here is...? sizeof(variable), sizeof(*variable),
sizeof(type) gives the size, no matter what.

The point is maintainability.

Suppose the initial version of your program has:

int *p;
p = malloc(some_number * sizeof(int));

Later, you change the type of p from int* to long* -- but you forget
to change the malloc call, introducing a bug that takes hours or days
to track down. It could take even longer if int and long happen to be
the same size on your development platform, and the bug has no
symptoms until you port to another system months later.

Using sizeof *p avoids this.
And (do not take this too
personally), it's better to put in the parenthesis, to diminish
confusion.

I'm not entirely unsympathetic to that point, but sizeof is a unary
operator, not a function. Its name just happens to be spelled with
letters rather than punctuation marks. It's no more necessary to
parenthesize the argument in "sizeof var" than in "- var". There are,
of course, cases where parentheses add to clarity, but once you
understand what's going on with sizeof, I don't think this is one of
them.
 
T

Tim Rentsch

Some people say sizeof(type) and other say sizeof(variable).
Why?

I've been reading the thread discussing 'sizeof' and its usage with
interest. I've gone back and forth a bit in my own development
practices for using sizeof, and the discussion has sharpened
my views enough so I'm ready to offer my $0.02 now.

Executive summary - prefer sizeof(x), sizeof(*p) to sizeof(type).

First, the starting question, 'sizeof(type)' or 'sizeof(variable)'?
Looking through several hundred thousand lines of code, I'm convinced
'sizeof(variable)' [or 'sizeof(expression)'] is almost always better
than 'sizeof(type)'. Using 'sizeof(type)' is similar to using "magic
numbers" in open code - better to relegate those few cases that really
need to do 'sizeof(type)' to #defines, and then use the symbolic name.

Second, to parenthesize or not parenthesize? I think the easiest way
to think of 'sizeof' is as a special kind of macro, much like the
special macro 'offsetof()', and just always use parentheses. I know
that technically that isn't right, but it's easy to explain, easy to
remember, and reduces cognitive load when reading code. What about
people who use the 'sizeof x' form, without parentheses? I wouldn't
object to that too strongly, kind of put it in the category of writing
indexing with the integer on the outside, eg, 0[p] -- experts do it,
and if one wants to be considered an expert one should know about it,
but it's not necessary to use it just because you can.

Third, related topic, sharing a little macro definition that I've
found useful:

#define bitsizeof(x) (sizeof(x) * CHAR_BIT)

Of course this needs a #include <limits.h> to work properly.
 
M

Michael Wojcik

On Fri, 10 Jun 2005 21:30:56 +0000 (UTC), Malcolm

Except that it's a compile-time function. But I agree that in a
mathematical sense the result is a function of the (type of the)
parameter. I don't think that it's really an operator, it doesn't
operate on anything.

Nonsense. Mathematical operators *are* functions - there's no
relevant distinction there. sizeof is a unary operator, and it
operates on its argument, mapping from the domain that's the union of
{identifiers naming complete types} and {identifiers naming objects
of complete type}, to the range [0,SIZE_MAX].

It's just as much an operator as, say, unary negation (-) or bitwise
negation (~). It happens to have a different domain and range, but
that doesn't magically change it from an "operator" to a "function" -
that's a meaningless distinction in mathematics, and simply wrong in
C.

An operator or function only "doesn't operate on anything" if its
domain is the empty set. sizeof takes an argument; thus it operates
on something.
IMO, yes. It also ensures that it avoids ambiguity:

malloc(sizeof x * y)

is visually ambiguous, since unlike the ordinary operators the
precedence is not obvious (OK, the precedence of bit operators is odd as
well, so I always fully parenthesise those).

What's "visually ambiguous" depends on the reader. Do you find unary
negation ambiguous in the same context? Your argument applies just
as well to it.

--
Michael Wojcik (e-mail address removed)

Art is our chief means of breaking bread with the dead ... but the social
and political history of Europe would be exactly the same if Dante and
Shakespeare and Mozart had never lived. -- W. H. Auden
 
L

Lawrence Kirby

On Mon, 13 Jun 2005 15:12:55 +0000, Michael Wojcik wrote:

....
It's just as much an operator as, say, unary negation (-) or bitwise
negation (~). It happens to have a different domain and range, but
that doesn't magically change it from an "operator" to a "function" -
that's a meaningless distinction in mathematics, and simply wrong in
C.

An operator or function only "doesn't operate on anything" if its
domain is the empty set. sizeof takes an argument; thus it operates
on something.

Functions have arguments, operators have operands. :)

Lawrence
 
T

Tim Rentsch

Lawrence Kirby said:
On Mon, 13 Jun 2005 15:12:55 +0000, Michael Wojcik wrote:

......


Functions have arguments, operators have operands. :)

Functions have parameters.

Function calls (and sometimes comp.lang.c contributors) have arguments.
 
J

Jean-Claude Arbaut

Le 13/06/2005 23:51, dans (e-mail address removed), « Tim
Rentsch » said:
Functions have parameters.

Function calls (and sometimes comp.lang.c contributors) have arguments.

In french we say "chipoteur", I think it's quibbling in english ;-)
This is just an argument argument :-D
 
T

Tim Rentsch

Jean-Claude Arbaut said:
Le 13/06/2005 23:51, dans (e-mail address removed), « Tim


In french we say "chipoteur", I think it's quibbling in english ;-)
This is just an argument argument :-D

I should have added a smiley. My comments were intended
primarily as humor.
 
L

Lawrence Kirby

Functions have parameters.

Function calls (and sometimes comp.lang.c contributors) have arguments.

However this was in the context of an operator invocation/function call. :)

Lawrence
 
J

Jean-Claude Arbaut

Le 15/06/2005 18:58, dans (e-mail address removed),
« Emmanuel Delahaye » said:
Jean-Claude Arbaut wrote on 13/06/05 :

'F'rench ... 'E'nglish ...

'picky' is the word you are looking for.

But the first line is much more expressive :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top