Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #63160 > unrolled thread

sizeof(arr[0])

Back to article view | Back to comp.lang.c

Contents

  sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 12:38 -0700
    Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-10 16:00 -0400
      Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 14:53 -0700
    Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 13:11 -0700
    Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-10 21:21 +0100
      Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-10 22:08 +0100
        Re: sizeof(arr[0]) Andrew Cooper <amc96@cam.ac.uk> - 2015-06-11 00:27 +0100
          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:34 +0100
            Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:38 +0100
            Re: writing code for people who don't know the language (was: sizeof(arr[0])) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-06-10 21:16 -0400
            Re: writing code for people who don't know the language Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 02:35 +0100
              Re: writing code for people who don't know the language Bartc <bc@freeuk.com> - 2015-06-11 11:16 +0100
            Re: writing code for people who don't know the language Bartc <bc@freeuk.com> - 2015-06-11 11:29 +0100
              Re: writing code for people who don't know the language gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-11 11:43 +0000
            Re: sizeof(arr[0]) Paul N <gw7rib@aol.com> - 2015-06-14 13:13 -0700
              Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-14 17:52 -0700
            Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 14:26 -0400
              Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 19:34 +0100
                Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 14:55 -0400
                  Re: sizeof(arr[0]) Melzzzzz <melz@zzzzz.com> - 2015-06-15 20:59 +0200
                  Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-15 20:11 +0100
                    Re: sizeof(arr[0]) "Bill Cunningham" <nospam@nspam.invalid> - 2015-06-15 15:22 -0400
                      Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-16 09:51 -0700
                        Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 10:51 -0700
                          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 19:14 +0100
                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:43 -0700
                              Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 20:03 +0100
                          Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 19:15 +0100
                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:34 -0700
                              Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-16 20:28 +0100
                                Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 15:42 -0400
                                  Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:35 -0700
                                    Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 16:59 -0400
                                    Re: sizeof(arr[0]) Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-16 22:05 +0100
                                      Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 14:27 -0700
                                        Re: sizeof(arr[0]) Dr Nick <nospam-4@temporary-address.org.uk> - 2015-06-17 07:07 +0100
                                  Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 01:22 +0100
                                Re: sizeof(arr[0]) glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-06-16 19:45 +0000
                                Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:03 -0700
                                  Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 10:58 +0100
                                    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 05:58 -0700
                                      Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 15:46 +0100
                                        Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 08:14 -0700
                                          Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-17 17:58 +0100
                                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:07 -0700
                                              Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 10:09 -0700
                                                Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:46 -0700
                                              Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 11:13 -0700
                                                Re: sizeof(arr[0]) Nathan Wagner <nw@hydaspes.if.org> - 2015-06-18 07:14 +0000
                                                  Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-18 09:54 +0200
                                                  Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-18 05:19 -0700
                                          Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 10:53 -0700
                                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 11:17 -0700
                                              Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 13:59 -0700
                                                Re: sizeof(arr[0]) Ian Collins <ian-news@hotmail.com> - 2015-06-18 13:41 +1200
                                            Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:04 +0200
                              Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:18 -0700
                                Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 21:30 +0100
                                  Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:53 -0700
                                Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 13:43 -0700
                                  Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 21:52 +0100
                                    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:01 -0700
                                    Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-16 23:49 +0200
                                      Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:58 -0700
                                        Re: sizeof(arr[0]) David Brown <david.brown@hesbynett.no> - 2015-06-17 14:10 +0200
                                          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 13:20 +0100
                                  Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 14:16 -0700
                                    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 14:39 -0700
                          Re: sizeof(arr[0]) gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-16 18:38 +0000
                            Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-16 11:45 -0700
                              Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 13:22 -0700
                                Re: sizeof(arr[0]) gazelle@shell.xmission.com (Kenny McCormack) - 2015-06-16 21:25 +0000
                        Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-16 11:05 -0700
                          Re: sizeof(arr[0]) James Kuyper <jameskuyper@verizon.net> - 2015-06-16 14:15 -0400
                          Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:07 -0700
                            Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-17 11:16 -0700
                              Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 10:22 -0700
                                Re: sizeof(arr[0]) Keith Thompson <kst-u@mib.org> - 2015-06-18 10:42 -0700
                                  Re: sizeof(arr[0]) David Kleinecke <dkleinecke@gmail.com> - 2015-06-18 11:41 -0700
                    Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-16 00:12 -0700
                      Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 10:12 +0100
                        Re: sizeof(arr[0]) Philip Lantz <prl@canterey.us> - 2015-06-16 09:12 -0700
                          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-16 17:32 +0100
      Re: sizeof(arr[0]) kuznecov.alexey@gmail.com - 2015-06-10 14:56 -0700
        Re: sizeof(arr[0]) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-06-10 23:53 +0100
        Re: sizeof(arr[0]) Bartc <bc@freeuk.com> - 2015-06-11 00:33 +0100
          Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-11 00:37 +0100
    Re: sizeof(arr[0]) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 06:05 -0700
      [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-17 16:07 +0200
        Re: [OT] The number 42 (was Re: sizeof(arr[0])) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-06-17 08:23 -0700
          Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:21 +0200
        Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Kleinecke <dkleinecke@gmail.com> - 2015-06-17 10:35 -0700
          Re: [OT] The number 42 (was Re: sizeof(arr[0])) David Brown <david.brown@hesbynett.no> - 2015-06-18 10:18 +0200
            Re: [OT] The number 42 (was Re: sizeof(arr[0])) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-18 10:08 +0100
      Re: sizeof(arr[0]) Richard Heathfield <rjh@cpax.org.uk> - 2015-06-17 15:13 +0100
        Re: sizeof(arr[0]) raltbos@xs4all.nl (Richard Bos) - 2015-06-18 20:38 +0000

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#63311

On 15/06/15 19:55, Bill Cunningham wrote:
> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
> news:mln5pk$2vb$1@dont-email.me...
>
>> int is indeed a built-in type, but sizeof (int p) is merely a syntax
>> error. If you mean the size of p, use sizeof p. If you mean the size of
>> the type of object pointed to by p, use sizeof *p.
>
>      I thought sizeof (int p) kind of looked funny. One could use sizeof
> (int) too I would suppose. So sizeof *p is saying sizeof the "point to int"

sizeof *p means "the size of the type of object pointed to by p".

> or is the * a dereference here?

Notionally, yes, but no evaluation takes place (unless p is a 
variable-length array, which it isn't in this case). The expression 
sizeof *p can be thought of as: "for a pointer type p, consider the type 
of the object to which p can point - what is the size of that object in 
bytes?"


> But he's wanting a "dynamic array" so the
> size needs to change in the code at the applicable place.

He is *calculating* the amount of storage required for n items of a size 
appropriate for storing items of the type pointed to by p. The size of 
the type pointed to by p is garnered from sizeof *p, and multiplying 
this by n gives the total amount of storage to be requested from malloc.

>      That bring up to me something else. What about sizeof (int *) is that
> valid? I know I should know, but I have so many other things to do too.

Yes, sizeof (int *) is valid too, although I would not recommend it. It 
yields the number of bytes required to store a pointer-to-int. The 
problem with it is as follows:

int *p;
p = malloc(n * sizeof(int *));
if(p != NULL)
{
   start filling p[0] to p[n - 1] with ints

All well and good, until the programmer decides that he actually meant 
for p to be a double* instead. If he or she forgets to change the malloc 
line to sizeof(double *), there may well not be enough storage to hold n 
lots of double (and in fact there almost certainly won't be).

By writing:

p = malloc(n * sizeof *p);

instead, the programmer guards against this possibility because, if the 
programmer changes the type of p in the declaration, the amount of 
storage allocated will automatically change in line with the type change.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#63313

"Richard Heathfield" <rjh@cpax.org.uk> wrote in message 
news:mln7ui$c88$1@dont-email.me...
> On 15/06/15 19:55, Bill Cunningham wrote:
>> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
>> news:mln5pk$2vb$1@dont-email.me...
>>
>>> int is indeed a built-in type, but sizeof (int p) is merely a syntax
>>> error. If you mean the size of p, use sizeof p. If you mean the size of
>>> the type of object pointed to by p, use sizeof *p.
>>
>>      I thought sizeof (int p) kind of looked funny. One could use sizeof
>> (int) too I would suppose. So sizeof *p is saying sizeof the "point to 
>> int"
>
> sizeof *p means "the size of the type of object pointed to by p".
>
>> or is the * a dereference here?
>
> Notionally, yes, but no evaluation takes place (unless p is a 
> variable-length array, which it isn't in this case). The expression sizeof 
> *p can be thought of as: "for a pointer type p, consider the type of the 
> object to which p can point - what is the size of that object in bytes?"
>
>
>> But he's wanting a "dynamic array" so the
>> size needs to change in the code at the applicable place.
>
> He is *calculating* the amount of storage required for n items of a size 
> appropriate for storing items of the type pointed to by p. The size of the 
> type pointed to by p is garnered from sizeof *p, and multiplying this by n 
> gives the total amount of storage to be requested from malloc.
>
>>      That bring up to me something else. What about sizeof (int *) is 
>> that
>> valid? I know I should know, but I have so many other things to do too.
>
> Yes, sizeof (int *) is valid too, although I would not recommend it. It 
> yields the number of bytes required to store a pointer-to-int. The problem 
> with it is as follows:
>
> int *p;
> p = malloc(n * sizeof(int *));
> if(p != NULL)
> {
>   start filling p[0] to p[n - 1] with ints
>
> All well and good, until the programmer decides that he actually meant for 
> p to be a double* instead. If he or she forgets to change the malloc line 
> to sizeof(double *), there may well not be enough storage to hold n lots 
> of double (and in fact there almost certainly won't be).
>
> By writing:
>
> p = malloc(n * sizeof *p);
>
> instead, the programmer guards against this possibility because, if the 
> programmer changes the type of p in the declaration, the amount of storage 
> allocated will automatically change in line with the type change.

    Got it. Now if I can just remeber this if I ever need it ;)

Bill

[toc] | [prev] | [next] | [standalone]

#63350

On Monday, June 15, 2015 at 12:22:55 PM UTC-7, Bill Cunningham wrote:
> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message 
> news:mln7ui$c88$1@dont-email.me...
> > On 15/06/15 19:55, Bill Cunningham wrote:
> >> "Richard Heathfield" <rjh@cpax.org.uk> wrote in message
> >> news:mln5pk$2vb$1@dont-email.me...
> >>
> >>> int is indeed a built-in type, but sizeof (int p) is merely a syntax
> >>> error. If you mean the size of p, use sizeof p. If you mean the size of
> >>> the type of object pointed to by p, use sizeof *p.
> >>
> >>      I thought sizeof (int p) kind of looked funny. One could use sizeof
> >> (int) too I would suppose. So sizeof *p is saying sizeof the "point to 
> >> int"
> >
> > sizeof *p means "the size of the type of object pointed to by p".
> >
> >> or is the * a dereference here?
> >
> > Notionally, yes, but no evaluation takes place (unless p is a 
> > variable-length array, which it isn't in this case). The expression sizeof 
> > *p can be thought of as: "for a pointer type p, consider the type of the 
> > object to which p can point - what is the size of that object in bytes?"
> >
> >
> >> But he's wanting a "dynamic array" so the
> >> size needs to change in the code at the applicable place.
> >
> > He is *calculating* the amount of storage required for n items of a size 
> > appropriate for storing items of the type pointed to by p. The size of the 
> > type pointed to by p is garnered from sizeof *p, and multiplying this by n 
> > gives the total amount of storage to be requested from malloc.
> >
> >>      That bring up to me something else. What about sizeof (int *) is 
> >> that
> >> valid? I know I should know, but I have so many other things to do too.
> >
> > Yes, sizeof (int *) is valid too, although I would not recommend it. It 
> > yields the number of bytes required to store a pointer-to-int. The problem 
> > with it is as follows:
> >
> > int *p;
> > p = malloc(n * sizeof(int *));
> > if(p != NULL)
> > {
> >   start filling p[0] to p[n - 1] with ints
> >
> > All well and good, until the programmer decides that he actually meant for 
> > p to be a double* instead. If he or she forgets to change the malloc line 
> > to sizeof(double *), there may well not be enough storage to hold n lots 
> > of double (and in fact there almost certainly won't be).
> >
> > By writing:
> >
> > p = malloc(n * sizeof *p);
> >
> > instead, the programmer guards against this possibility because, if the 
> > programmer changes the type of p in the declaration, the amount of storage 
> > allocated will automatically change in line with the type change.
> 
>     Got it. Now if I can just remeber this if I ever need it ;)
> 
> Bill

One way to think of it is that "sizeof (int)" is the sizeof operator 
acting on a type cast and "sizeof x" is the operator acting on a 
variable (like "& x") - and to forget that "sizeof (x)" is possible. 

[toc] | [prev] | [next] | [standalone]

#63354

On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
> One way to think of it is that "sizeof (int)" is the sizeof operator 
> acting on a type cast and "sizeof x" is the operator acting on a 
> variable (like "& x") - and to forget that "sizeof (x)" is possible.

It's why sizeof should always be sizeof(), and never sizeof.  I feel
the same way about return (it should always be return() rather than
return, and the same for other similar keywords).

Enclosing in parentheses removes ambiguity and helps document exactly
what's happening without needing to have a comprehensive understanding
of the peculiarities of syntax on certain compiler keywords.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#63357

On 16/06/15 18:51, Rick C. Hodgin wrote:
> On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
>> One way to think of it is that "sizeof (int)" is the sizeof operator
>> acting on a type cast and "sizeof x" is the operator acting on a
>> variable (like "& x") - and to forget that "sizeof (x)" is possible.
>
> It's why sizeof should always be sizeof(), and never sizeof.

The sizeof operator is an operator, not a function call. It is almost 
never necessary to use parentheses for sizeof in well-written C code. It 
adds no value, and distracts the reader. You are entitled to your 
opinion, of course, but I can't say I find it a helpful one.

> I feel
> the same way about return (it should always be return() rather than
> return, and the same for other similar keywords).

Again I must disagree. For one thing, it doesn't work in void functions; 
return() is a syntax error. So you /can't/ always use return(). What's 
more, it adds no value, and distracts the reader. Again, you are 
entitled to your opinion, but it is not one to which I could subscribe.

> Enclosing in parentheses removes ambiguity and helps document exactly
> what's happening without needing to have a comprehensive understanding
> of the peculiarities of syntax on certain compiler keywords.

There is no particularly significant peculiarity of syntax in either 
sizeof or return. The only very minor peculiarity of sizeof is that it 
accepts a parenthesised type as an operand. But the parentheses /are/ 
the oddity. If you take the size of objects rather than types, the 
peculiarity almost never appears.

There is a case for using parentheses to make the intended 
operand-operator groupings clearer to the reader where the precedence 
isn't necessarily one that is widely memorised:

w = x << y | z; /* clear */
w = (x << y) | z; /* clearER, if the reader's in a hurry */

But parenthesising operands for the sake of it:

++(i);

is just silly.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#63365

On Tuesday, June 16, 2015 at 2:14:50 PM UTC-4, Richard Heathfield wrote:
> On 16/06/15 18:51, Rick C. Hodgin wrote:
> > On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
> >> One way to think of it is that "sizeof (int)" is the sizeof operator
> >> acting on a type cast and "sizeof x" is the operator acting on a
> >> variable (like "& x") - and to forget that "sizeof (x)" is possible.
> >
> > It's why sizeof should always be sizeof(), and never sizeof.
> 
> The sizeof operator is an operator, not a function call. It is almost 
> never necessary to use parentheses for sizeof in well-written C code. It 
> adds no value, and distracts the reader. You are entitled to your 
> opinion, of course, but I can't say I find it a helpful one.
> 
> > I feel
> > the same way about return (it should always be return() rather than
> > return, and the same for other similar keywords).
> 
> Again I must disagree. For one thing, it doesn't work in void functions; 
> return() is a syntax error. So you /can't/ always use return(). What's 
> more, it adds no value, and distracts the reader. Again, you are 
> entitled to your opinion, but it is not one to which I could subscribe.
> 
> > Enclosing in parentheses removes ambiguity and helps document exactly
> > what's happening without needing to have a comprehensive understanding
> > of the peculiarities of syntax on certain compiler keywords.
> 
> There is no particularly significant peculiarity of syntax in either 
> sizeof or return.

The example above explains it all:

    sizeof(*p)->x

A person reading that would cringe (at least they should). It's one of
those C quirks along the lines of *tnX++; where tnX is an int*. :-)

> The only very minor peculiarity of sizeof is that it 
> accepts a parenthesised type as an operand. But the parentheses /are/ 
> the oddity. If you take the size of objects rather than types, the 
> peculiarity almost never appears.

In my code they are not an oddity.  They are the norm.  If I ever came
across a sizeof() without parenthesis, I would quickly fix the bug and
wonder in the back of my mind what's wrong with the compiler that it
did not generate an error on that clearly incorrect line of code I'd
written in what was obviously a lucid-free moment. :-)

> There is a case for using parentheses to make the intended 
> operand-operator groupings clearer to the reader where the precedence 
> isn't necessarily one that is widely memorised:
> 
> w = x << y | z; /* clear */
> w = (x << y) | z; /* clearER, if the reader's in a hurry */

I disagree that the first one is clear. It requires that someone know
the order of operations. In the second example, a person does not need
to know the order of operations and will still be able to realize that
the (x << y) must be computed first, even if they still don't know what
the << is.

> But parenthesising operands for the sake of it:
> ++(i);
> is just silly.

Agreed.  However, this is always much clearer:

    ((a) ? b : c)

This type of expression must always be surrounded with parenthesis.
It's just the way it goes in C.  To do otherwise is to do otherwise.
:-)

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#63368

On 16/06/15 19:43, Rick C. Hodgin wrote:

<snip>

> The example above explains it all:
>
>      sizeof(*p)->x
>
> A person reading that would cringe (at least they should).

I don't see why. It seems pretty clear to me. p is a pointer to a 
pointer to struct. We want to deref the "outer" pointer to get at the 
inner pointer, deref that using -> to get an object x, and find that 
object's size. That C can say such a complicated thing so easily is a 
good thing. I am not convinced that sizeof((*p)->x) is clearer!

> It's one of
> those C quirks along the lines of *tnX++; where tnX is an int*. :-)

Well, it's certainly true that it is legal, in C, to produce a result 
that you then don't use. This is sometimes useful for the side effects 
(for example, when calling printf, we rarely bother to use the value it 
returns). But in *tnX++; the * is of course without merit.

>
>> The only very minor peculiarity of sizeof is that it
>> accepts a parenthesised type as an operand. But the parentheses /are/
>> the oddity. If you take the size of objects rather than types, the
>> peculiarity almost never appears.
>
> In my code they are not an oddity.  They are the norm.

Since I don't anticipate that either of us is likely to be maintaining 
the other's code any time soon, I don't suppose that's a problem. :-)


> If I ever came
> across a sizeof() without parenthesis, I would quickly fix the bug

And if I ever came across a sizeof /with/ parentheses, I would pause to 
make sure I could safely remove them (which, in almost all cases in my 
own code, I could), and /then/ fix what you would refuse to envisage as 
a bug.

>> There is a case for using parentheses to make the intended
>> operand-operator groupings clearer to the reader where the precedence
>> isn't necessarily one that is widely memorised:
>>
>> w = x << y | z; /* clear */
>> w = (x << y) | z; /* clearER, if the reader's in a hurry */
>
> I disagree that the first one is clear. It requires that someone know
> the order of operations.

That's why the second one is clearER.

> In the second example, a person does not need
> to know the order of operations and will still be able to realize that
> the (x << y) must be computed first, even if they still don't know what
> the << is.

If they don't know what << is, they've got no business editing 
production code. But they can be forgiven for not memorising the 
relative precedence of << and |.

>> But parenthesising operands for the sake of it:
>> ++(i);
>> is just silly.
>
> Agreed.  However, this is always much clearer:
>
>      ((a) ? b : c)

I'd /almost/ agree with you there. I just wouldn't go quite so far as to 
say "always".

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#63359

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
>> One way to think of it is that "sizeof (int)" is the sizeof operator 
>> acting on a type cast and "sizeof x" is the operator acting on a 
>> variable (like "& x") - and to forget that "sizeof (x)" is possible.
>
> It's why sizeof should always be sizeof(), and never sizeof.  I feel
> the same way about return (it should always be return() rather than
> return, and the same for other similar keywords).

Do you write long(x); ++(p) and/or *(p) all the time?

> Enclosing in parentheses removes ambiguity and helps document exactly
> what's happening without needing to have a comprehensive understanding
> of the peculiarities of syntax on certain compiler keywords.

What possible ambiguity is there in return 42; that is dispelled by
writing return(42);?  (Or pick your own example if I've
over-simplified.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#63363

On Tuesday, June 16, 2015 at 2:15:27 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> 
> > On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
> >> One way to think of it is that "sizeof (int)" is the sizeof operator 
> >> acting on a type cast and "sizeof x" is the operator acting on a 
> >> variable (like "& x") - and to forget that "sizeof (x)" is possible.
> >
> > It's why sizeof should always be sizeof(), and never sizeof.  I feel
> > the same way about return (it should always be return() rather than
> > return, and the same for other similar keywords).
> 
> Do you write long(x); ++(p) and/or *(p) all the time?

Yes. Every time. :-)

No, of course not. But I do write it on things like sizeof(), and
other similar things because I do look at them as a type of function.

These operators take some input and return a value there in immediate
context. They do so with a name and not a character or character set.
And just because they don't go through runtime code is of no real
difference to me because from a source code point of view I am giving
sizeof some input, and it is giving me some output. As such ... function,
just one that happens to be a compile-time function, rather than runtime.

> > Enclosing in parentheses removes ambiguity and helps document exactly
> > what's happening without needing to have a comprehensive understanding
> > of the peculiarities of syntax on certain compiler keywords.
> 
> What possible ambiguity is there in return 42; that is dispelled by
> writing return(42);?  (Or pick your own example if I've
> over-simplified.)

None.  There's also no ambiguity in return x; or return result;  I
prefer for it to be return(42);, return(x), and return(result).  I
view those also as functions because I am giving it some input, and
it is giving me an output (which happens to be the same value, though
in some cases it is cast through a function, such as "return(2);" when
2 must be translated to a float.  As such ... function, just one that
happens to be a compile-time function, rather than runtime.

It's my personal taste on this matter, but I believe there's some real
foundation there as these various named things actually can perform
functions.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#63369

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, June 16, 2015 at 2:15:27 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> 
>> > On Tuesday, June 16, 2015 at 12:51:42 PM UTC-4, David Kleinecke wrote:
>> >> One way to think of it is that "sizeof (int)" is the sizeof operator 
>> >> acting on a type cast and "sizeof x" is the operator acting on a 
>> >> variable (like "& x") - and to forget that "sizeof (x)" is possible.
>> >
>> > It's why sizeof should always be sizeof(), and never sizeof.  I feel
>> > the same way about return (it should always be return() rather than
>> > return, and the same for other similar keywords).
>> 
>> Do you write long(x); ++(p) and/or *(p) all the time?
>
> Yes. Every time. :-)
>
> No, of course not. But I do write it on things like sizeof(), and
> other similar things because I do look at them as a type of function.
>
> These operators take some input and return a value there in immediate
> context. They do so with a name and not a character or character set.
> And just because they don't go through runtime code is of no real
> difference to me because from a source code point of view I am giving
> sizeof some input, and it is giving me some output. As such ... function,
> just one that happens to be a compile-time function, rather than
> runtime.

Would it be fair, then, to say that it's just because sizeof is an
operator written using letters that you want to write it like a function
call?

For me, the very fact that it is so different to a function call is the
reason I've moved more and more towards not writing like one.

>> > Enclosing in parentheses removes ambiguity and helps document
>> > exactly what's happening without needing to have a comprehensive
>> > understanding of the peculiarities of syntax on certain compiler
>> > keywords.
>> 
>> What possible ambiguity is there in return 42; that is dispelled by
>> writing return(42);?  (Or pick your own example if I've
>> over-simplified.)
>
> None.

OK, but you can see, I hope, why I might have thought otherwise.  You
said, after all, "Enclosing in parentheses removes ambiguity" so it not
unreasonable of me to think you though the ()s removed some ambiguity.

> There's also no ambiguity in return x; or return result;  I
> prefer for it to be return(42);, return(x), and return(result).  I
> view those also as functions because I am giving it some input, and
> it is giving me an output (which happens to be the same value, though
> in some cases it is cast through a function, such as "return(2);" when
> 2 must be translated to a float.  As such ... function, just one that
> happens to be a compile-time function, rather than runtime.

Ah.  If you think of return as a function we are on different planets.

> It's my personal taste on this matter, but I believe there's some real
> foundation there as these various named things actually can perform
> functions.

Yes, of course.  I ask simply because I am so often surprised by the
distance between plants.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#63370

On 06/16/2015 03:28 PM, Ben Bacarisse wrote:
...
> Would it be fair, then, to say that it's just because sizeof is an
> operator written using letters that you want to write it like a function
> call?
> 
> For me, the very fact that it is so different to a function call is the
> reason I've moved more and more towards not writing like one.

All of the following keywords introduced in C2011 use the same type of
syntax as a function call, but none of them are functions as far as C is
concerned. How do you feel about them? _Alignas, _Alignof, _Atomic,
_Generic, _Static_assert.

_Alignof is the only one of those that is described as an operator. Only
_Alignof and _Generic form expressions.

[toc] | [prev] | [next] | [standalone]

#63376

James Kuyper <jameskuyper@verizon.net> writes:
> On 06/16/2015 03:28 PM, Ben Bacarisse wrote:
> ...
>> Would it be fair, then, to say that it's just because sizeof is an
>> operator written using letters that you want to write it like a function
>> call?
>> 
>> For me, the very fact that it is so different to a function call is the
>> reason I've moved more and more towards not writing like one.
>
> All of the following keywords introduced in C2011 use the same type of
> syntax as a function call, but none of them are functions as far as C is
> concerned. How do you feel about them? _Alignas, _Alignof, _Atomic,
> _Generic, _Static_assert.
>
> _Alignof is the only one of those that is described as an operator. Only
> _Alignof and _Generic form expressions.

They don't really have the same syntax as a function call.

For example, _Alignof (unlike sizeof) can only be applied to a
parenthesized type name.  _Atomic can be used either by itself (as a
type specifier like "const") or followed by a parenthesized type name
(which makes it a type specifier); neither is particularly
function-like.  _Generic is followed by some stuff in parentheses, but
that stuff is not a sequence of expressions separated by commas.  And so
forth.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#63380

On 06/16/2015 04:35 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 06/16/2015 03:28 PM, Ben Bacarisse wrote:
...
>>> For me, the very fact that it is so different to a function call is the
>>> reason I've moved more and more towards not writing like one.
>>
>> All of the following keywords introduced in C2011 use the same type of
>> syntax as a function call, but none of them are functions as far as C is
>> concerned. How do you feel about them? _Alignas, _Alignof, _Atomic,
>> _Generic, _Static_assert.
>>
>> _Alignof is the only one of those that is described as an operator. Only
>> _Alignof and _Generic form expressions.
> 
> They don't really have the same syntax as a function call.
> 
> For example, _Alignof (unlike sizeof) can only be applied to a
> parenthesized type name.  _Atomic can be used either by itself (as a
> type specifier like "const") or followed by a parenthesized type name
> (which makes it a type specifier); neither is particularly
> function-like.  _Generic is followed by some stuff in parentheses, but
> that stuff is not a sequence of expressions separated by commas.  And so
> forth.

True. However, someone who can look at sizeof(int) and conclude that it
"looks like a function" can only have done so by concentrating his
attention on the '(' and ')', and ignoring everything that occurs
between them. The same "analysis" applied to _Alignof() and _Generic()
should therefore reach the same conclusion.

In order to conclude that _Alignas() or _Atomic() "looks like a
function", you'd also have to ignore the fact that they don't have a
value, and can only be used as declaration specifiers. In order to reach
that conclusion about _Static_assert(), you'd have to ignore the fact
that it considered to be a declaration. However, I have confidence that
most people who would think that sizeof(long double) looks like a
function call could manage somehow to consider those to be function
calls as well.

[toc] | [prev] | [next] | [standalone]

#63382

Keith Thompson <kst-u@mib.org> writes:

> James Kuyper <jameskuyper@verizon.net> writes:
>> On 06/16/2015 03:28 PM, Ben Bacarisse wrote:
>> ...
>>> Would it be fair, then, to say that it's just because sizeof is an
>>> operator written using letters that you want to write it like a function
>>> call?
>>> 
>>> For me, the very fact that it is so different to a function call is the
>>> reason I've moved more and more towards not writing like one.
>>
>> All of the following keywords introduced in C2011 use the same type of
>> syntax as a function call, but none of them are functions as far as C is
>> concerned. How do you feel about them? _Alignas, _Alignof, _Atomic,
>> _Generic, _Static_assert.
>>
>> _Alignof is the only one of those that is described as an operator. Only
>> _Alignof and _Generic form expressions.
>
> They don't really have the same syntax as a function call.
>
> For example, _Alignof (unlike sizeof) can only be applied to a
> parenthesized type name. [snip]

Out of sheer curiosity, why is that?  Is there a reason why it couldn't
work like sizeof?  After all, every expression has a type, so must also
have the alignment of that type.

[toc] | [prev] | [next] | [standalone]

#63385

Dr Nick <nospam-4@temporary-address.org.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> James Kuyper <jameskuyper@verizon.net> writes:
>>> On 06/16/2015 03:28 PM, Ben Bacarisse wrote:
>>> ...
>>>> Would it be fair, then, to say that it's just because sizeof is an
>>>> operator written using letters that you want to write it like a function
>>>> call?
>>>> 
>>>> For me, the very fact that it is so different to a function call is the
>>>> reason I've moved more and more towards not writing like one.
>>>
>>> All of the following keywords introduced in C2011 use the same type of
>>> syntax as a function call, but none of them are functions as far as C is
>>> concerned. How do you feel about them? _Alignas, _Alignof, _Atomic,
>>> _Generic, _Static_assert.
>>>
>>> _Alignof is the only one of those that is described as an operator. Only
>>> _Alignof and _Generic form expressions.
>>
>> They don't really have the same syntax as a function call.
>>
>> For example, _Alignof (unlike sizeof) can only be applied to a
>> parenthesized type name. [snip]
>
> Out of sheer curiosity, why is that?  Is there a reason why it couldn't
> work like sizeof?  After all, every expression has a type, so must also
> have the alignment of that type.

I don't know.

I asked about it on comp.std.c a while ago, and the response from
Larry Jones was "_Alignof came from C++, so you'd have to ask them.".
C++ has "alignof" as a keyword and permits only a parenthesized
type name.

Incidentally, parts of the N1570 draft of the C++ 11 standard
incorrectly assumed that _Alignof *can* be applied to an expression
(it lists it as one of the cases where an array expression is
not converted to a pointer).  That was corrected in the published
C11 standard.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#63391

Keith Thompson <kst-u@mib.org> writes:

> Dr Nick <nospam-4@temporary-address.org.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> James Kuyper <jameskuyper@verizon.net> writes:
>>>> On 06/16/2015 03:28 PM, Ben Bacarisse wrote:
>>>> ...
>>>>> Would it be fair, then, to say that it's just because sizeof is an
>>>>> operator written using letters that you want to write it like a function
>>>>> call?
>>>>> 
>>>>> For me, the very fact that it is so different to a function call is the
>>>>> reason I've moved more and more towards not writing like one.
>>>>
>>>> All of the following keywords introduced in C2011 use the same type of
>>>> syntax as a function call, but none of them are functions as far as C is
>>>> concerned. How do you feel about them? _Alignas, _Alignof, _Atomic,
>>>> _Generic, _Static_assert.
>>>>
>>>> _Alignof is the only one of those that is described as an operator. Only
>>>> _Alignof and _Generic form expressions.
>>>
>>> They don't really have the same syntax as a function call.
>>>
>>> For example, _Alignof (unlike sizeof) can only be applied to a
>>> parenthesized type name. [snip]
>>
>> Out of sheer curiosity, why is that?  Is there a reason why it couldn't
>> work like sizeof?  After all, every expression has a type, so must also
>> have the alignment of that type.
>
> I don't know.
>
> I asked about it on comp.std.c a while ago, and the response from
> Larry Jones was "_Alignof came from C++, so you'd have to ask them.".
> C++ has "alignof" as a keyword and permits only a parenthesized
> type name.

I don't think I care that much.  Thanks!

> Incidentally, parts of the N1570 draft of the C++ 11 standard
> incorrectly assumed that _Alignof *can* be applied to an expression
> (it lists it as one of the cases where an array expression is
> not converted to a pointer).  That was corrected in the published
> C11 standard.

Which makes it look clearly like a conscious decision and not an
oversight. Not that I've ever used it, and probably wouldn't want to use
it with an expression, but it seems pointlessly inconsistent.

[toc] | [prev] | [next] | [standalone]

#63389

James Kuyper <jameskuyper@verizon.net> writes:

> On 06/16/2015 03:28 PM, Ben Bacarisse wrote:
> ...
>> Would it be fair, then, to say that it's just because sizeof is an
>> operator written using letters that you want to write it like a function
>> call?
>> 
>> For me, the very fact that it is so different to a function call is the
>> reason I've moved more and more towards not writing like one.
>
> All of the following keywords introduced in C2011 use the same type of
> syntax as a function call, but none of them are functions as far as C is
> concerned. How do you feel about them? _Alignas, _Alignof, _Atomic,
> _Generic, _Static_assert.

They don't share much syntax with a function call but insofar as they do
I think it's unfortunate.  In some cases, it may be that the convenience
of capturing the syntax with a macro might have been appealing (and part
of the reason for the syntax) but I'm not sure how much of a practical
advantage this really is.

Anyway, since I write function calls like this: f(x), I can at least add
a space to write _Generic (x, int: 1, default: 0).  I'd probably have
chosen _Generic (x) { int: 1; default: 0 } (but I've not given it much
thought).

> _Alignof is the only one of those that is described as an operator. Only
> _Alignof and _Generic form expressions.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#63371

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
(snip, someone wrote)
>>> Do you write long(x); ++(p) and/or *(p) all the time?

>> Yes. Every time. :-)

>> No, of course not. But I do write it on things like sizeof(), and
>> other similar things because I do look at them as a type of function.

(snip)

> Would it be fair, then, to say that it's just because sizeof is an
> operator written using letters that you want to write it like a function
> call?

Having written both C and Fortran, it isn't so obvious what should
be a function and what should be an operator.

Fortran has the MOD function, C has the % operator.

Fortran has the ** operator, C has the pow() function.

And, for that matter, Fortran now has the C_SIZEOF function.

-- glen

[toc] | [prev] | [next] | [standalone]

#63372

On Tuesday, June 16, 2015 at 3:28:32 PM UTC-4, Ben Bacarisse wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> > These operators take some input and return a value there in immediate
> > context. They do so with a name and not a character or character set.
> > And just because they don't go through runtime code is of no real
> > difference to me because from a source code point of view I am giving
> > sizeof some input, and it is giving me some output. As such ... function,
> > just one that happens to be a compile-time function, rather than
> > runtime.
> 
> Would it be fair, then, to say that it's just because sizeof is an
> operator written using letters that you want to write it like a function
> call?

It's because of its operation, and because it's written using letters.
I don't think of typedef as a function, for example, though I do think
the syntax for typedef is confusing and I always find myself thinking
my way through non-trivial typedefs rather than garnering their meaning
at a glance.

This would make more sense to me:

    typedef (struct R_) R;
    typedef (unsigned char) u8;

Than this:

    typedef struct R_ R;
    typedef unsigned char u8;

At a glance my brain isolates the components of the first, whereas I
must read through the second, and it's just more difficult for me.

As it is I use this to accomplish the same thing (a visual cue to
help my brain isolate the two at a glance):

    typedef    struct R_          R;
    typedef    unsigned char      u8;

It now automatically groups things into columns, more easily
identifying subtle differences on each line.

> For me, the very fact that it is so different to a function call is the
> reason I've moved more and more towards not writing like one.

I don't think it's really that different from a function call. I think
it's only different when you don't use its function call-like syntax
form, and then it's nothing like a function call, and, in my opinion,
crosses the line into ambiguity land.

I just like to see input and output. I don't like those things to have
other meanings, but to be visualized mentally as real "machines" doing
"real work."

> >> > Enclosing in parentheses removes ambiguity and helps document
> >> > exactly what's happening without needing to have a comprehensive
> >> > understanding of the peculiarities of syntax on certain compiler
> >> > keywords.
> >> 
> >> What possible ambiguity is there in return 42; that is dispelled by
> >> writing return(42);?  (Or pick your own example if I've
> >> over-simplified.)
> >
> > None.
> 
> OK, but you can see, I hope, why I might have thought otherwise.  You
> said, after all, "Enclosing in parentheses removes ambiguity" so it not
> unreasonable of me to think you though the ()s removed some ambiguity.

I would argue that "return(42);" does remove ambiguity over "return 42;".
It's just that the level of ambiguity on that single source code line
containing "remove 42;" is very very low, and well below the threshold
of needing any kind of parenthesis prop.  However, "return(42);" is still
less ambiguous in my opinion.

As a result, I use return(x); everywhere in source code.

> > There's also no ambiguity in return x; or return result;  I
> > prefer for it to be return(42);, return(x), and return(result).  I
> > view those also as functions because I am giving it some input, and
> > it is giving me an output (which happens to be the same value, though
> > in some cases it is cast through a function, such as "return(2);" when
> > 2 must be translated to a float.  As such ... function, just one that
> > happens to be a compile-time function, rather than runtime.
> 
> Ah.  If you think of return as a function we are on different planets.

Same planet.  Different points of view looking at the same thing.

I place greater emphasis on the thing than on the convention.  The
fact is return does operate on the input provided to it, potentially
converting it into something else.  I view that as a function, because
in order to conduct that translation, some function is performed on my
source code. Whether it happens at runtime or compile-time is not
really something I need to care about. I just expect it to work as I've
indicated by source code, and to that end for ease of human reading, I
use parentheses.

> > It's my personal taste on this matter, but I believe there's some real
> > foundation there as these various named things actually can perform
> > functions.
> 
> Yes, of course.  I ask simply because I am so often surprised by the
> distance between plants.

Plants or planets? I ask because they're on much different scales,
and in reading your reply I'm trying to determine if it's centimeters
or AUs which surprise you. I hope it's not centimeters because I could
envision you then walking around, seeing the various things move all
around you, and then (because of the endless state of surprise) not
getting much done.

-----
FWIW, Ben, I really enjoy your posts. You have a keen knowledge and
insight and I appreciate it.  I feel the same way about several people
in this group, not the least of which is Keith Thompson (who I believe
has me on a news reader blacklist LOL!).

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#63394

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:

> On Tuesday, June 16, 2015 at 3:28:32 PM UTC-4, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> > These operators take some input and return a value there in immediate
>> > context. They do so with a name and not a character or character set.
>> > And just because they don't go through runtime code is of no real
>> > difference to me because from a source code point of view I am giving
>> > sizeof some input, and it is giving me some output. As such ... function,
>> > just one that happens to be a compile-time function, rather than
>> > runtime.
>> 
>> Would it be fair, then, to say that it's just because sizeof is an
>> operator written using letters that you want to write it like a function
>> call?
>
> It's because of its operation, and because it's written using letters.
> I don't think of typedef as a function, for example, though I do think
> the syntax for typedef is confusing and I always find myself thinking
> my way through non-trivial typedefs rather than garnering their meaning
> at a glance.
>
> This would make more sense to me:
>
>     typedef (struct R_) R;
>     typedef (unsigned char) u8;
>
> Than this:
>
>     typedef struct R_ R;
>     typedef unsigned char u8;
>
> At a glance my brain isolates the components of the first, whereas I
> must read through the second, and it's just more difficult for me.
>
> As it is I use this to accomplish the same thing (a visual cue to
> help my brain isolate the two at a glance):
>
>     typedef    struct R_          R;
>     typedef    unsigned char      u8;
>
> It now automatically groups things into columns, more easily
> identifying subtle differences on each line.
>
>> For me, the very fact that it is so different to a function call is the
>> reason I've moved more and more towards not writing like one.
>
> I don't think it's really that different from a function call. I think
> it's only different when you don't use its function call-like syntax
> form, and then it's nothing like a function call, and, in my opinion,
> crosses the line into ambiguity land.
>
> I just like to see input and output. I don't like those things to have
> other meanings, but to be visualized mentally as real "machines" doing
> "real work."
>
>> >> > Enclosing in parentheses removes ambiguity and helps document
>> >> > exactly what's happening without needing to have a comprehensive
>> >> > understanding of the peculiarities of syntax on certain compiler
>> >> > keywords.
>> >> 
>> >> What possible ambiguity is there in return 42; that is dispelled by
>> >> writing return(42);?  (Or pick your own example if I've
>> >> over-simplified.)
>> >
>> > None.
>> 
>> OK, but you can see, I hope, why I might have thought otherwise.  You
>> said, after all, "Enclosing in parentheses removes ambiguity" so it not
>> unreasonable of me to think you though the ()s removed some ambiguity.
>
> I would argue that "return(42);" does remove ambiguity over "return
> 42;".

So your answer to "what possible ambiguity is there in return 42; that
is dispelled by writing return(42);" is "none", but you would, none the
less, "argue that return(42); does remove ambiguity over return 42;".

Do you mean that there is no ambiguity but, despite that, you would
argue that there was simply for the sake of arguing?

<snip>
>> Ah.  If you think of return as a function we are on different planets.
>
> Same planet.  Different points of view looking at the same thing.

The analogy is intended to highlight the great distance between these
vantage points.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web