Live data from Hacker News

The Clockwise/Spiral Rule of C declarations

c-faq.com

51–60 of 72 posts

Re: The Clockwise/Spiral Rule of C declarations

#51

This has been posted before[1], and the "spiral rule" is a load of hooey. The correct rule is "follow the C grammar". An easier to remember and also correct rule is "start at the identifier being declared; work outwards from that point, reading right until you hit a closing parenthesis, then left until you hit the corresponding open parenthesis, then resume reading right..." (this is sometimes called the "right-left…

I used to complain about re-posts too. But now it is the first time i see a reference to this website, which seems interesting to me. So i'm happy with new url on my to-read list.

Thanks!

Re: The Clockwise/Spiral Rule of C declarations

#52
post #50

Earlier quoted context omitted.

Nope, * const means that the identifier (i.e. thing to the right of the star) is const. That is, in this example, the symbol "bar" is const, not anything that it points to. So once you dereference it, the const no longer matters.

You're right, I got confused. const is read as "the thing to the right of me is const". const * means const pointer, * const means pointer to const.

Vice versa. Const pointer:

    int *const p;
Pointer to const value:

    const int *p
    int const *p
>const is read as "the thing to the right of me is const"

const is one of storage classes and is read at its order, not just "to the right".

Re: The Clockwise/Spiral Rule of C declarations

#53
post #10
post #5

What makes me wonder is why C ended up with such a syntax. That is, its contemporary, Pascal, has a very straightforward, unambiguous syntax.

The C syntax is also unambiguous, and if you actually "get" C, it's what you'd naturally expect it to be.

unambiguous?

Have you ever had to write a C parser?

Re: The Clockwise/Spiral Rule of C declarations

#54
post #52
post #50

Earlier quoted context omitted.

You're right, I got confused. const is read as "the thing to the right of me is const". const * means const pointer, * const means pointer to const.

Vice versa. Const pointer: int *const p; Pointer to const value: const int *p int const *p >const is read as "the thing to the right of me is const" const is one of storage classes and is read at its order, not just "to the right".

Wow. I literally was staring at my test case when I wrote it and I _still_ got it wrong. I think I need to get some more sleep...

Re: The Clockwise/Spiral Rule of C declarations

#56

Contrast the first example with Golang: str [10]*byte which reads exactly as it is declared: "str is an array of length 10 of pointers to byte" (byte is Go equivalent of C char (mostly)).

But then you lose C's nice property that declaration and use are the same syntax.

For example, D also uses a similar type syntax, so in D if you declare:

  int[10][20] x;
  x[19][9] // is legal
In C:

  int x[10][20];
  x[9][19] // is legal
I think the correct solution would have been to make pointer syntax post-fix like the arrays and functions, so that you get the best of both worlds. Go-like declarations and C-like matchup between use and declarations.

Re: The Clockwise/Spiral Rule of C declarations

#57
post #53
post #10

Earlier quoted context omitted.

The C syntax is also unambiguous, and if you actually "get" C, it's what you'd naturally expect it to be.

unambiguous? Have you ever had to write a C parser?

Yes, it is unambiguous, even if it is context-sensitive.

If you don't have the available type names then it becomes ambiguous.

Re: The Clockwise/Spiral Rule of C declarations

#58
post #6
post #3

The rule is misleading in cases like: int* arr[][10]; Spiral rule would state "arr is an array of pointers to arrays of 10 ints", where actually it would be "arr is an array of array of 10 pointers to int". Instead, when you write declarations, do it from right-to-left, e.g.: char const* argv[]; "argv is an array of pointers to constant characters" It doesn't help with reading, unfortunately.

I think the advice that helped me the most was "Declaration follows usage". int* arr[][10]; If you index twice into arr and then dereference, you'll get an int. So arr must be an array of array of pointer to int.

To my mind that's one part of the reason the * belongs next to arr rather than next to int.

The other part is `int* x, y`.

Re: The Clockwise/Spiral Rule of C declarations

#59

Earlier quoted context omitted.

It'll certainly confuse people, but only those who aren't qualified to be doing anything with the code anyway. "complex" is subjective. It reminds me of stupid "rules" like "don't use the ternary operator", "every function must be less than 20 lines" (I am not exaggerating --- this was on a Java project, however); and you could easily extend that to "every statement must have a maximum of one operator", "you must not…

>> It'll certainly confuse people, but only those who aren't qualified to be doing anything with the code anyway. If the complexity can be avoided, why not avoid it. Removing complexity is not the same as dumb-downing code. It will improve readability and maintainability. This mindset is defintitely applicable to declaration as well as code construct. edit: clarity.

Note the last sentence of my comment. I am not advocating unwarranted complexity at all, but just saying that there are cases where an increase in local complexity can reduce overall complexity of the system, and you should not be afraid of using the language to the best of your ability.
Post reply on HN