Being taught this rule in undergrad really hampered my appreciation of C. As I've said in a previous comment, the real key that unlocked understanding C declarations for me is the mantra "declaration follows use." You declare a variable in C in exactly the same way you would use it: if you know how to use a variable, then you know how to read and write a declaration for it. Once I understood this elegant idea, it became hard to enjoy using statically typed languages that eschew it.
means that `*w` is an `int`, meaning `w` is a pointer to an `int`.
int *y[5]
(note that `◌[]` has higher precedence than `*◌`, so this is `*(y[5])`) means that `*y[5]` is an `int`, so `y[5]` is a pointer to an `int`, meaning `y` is an array of `int` pointers.
int (*(*kitchensink[5])(int, int))[6];
means that `(*(*kitchensink[5])(int, int))[6]` is an int, so
- `*(*kitchensink[5])(int, int)` is an array of `int`.
- `(*kitchensink[5])(int, int)` is a pointer to array of `int`.
- `kitchensink[5]` is a function pointer to a function that takes `(int, int)` and returns a pointer to an array of `int`.
- `kitchensink` is an array of function pointers to functions that take `(int, int)` and return a pointer to an array of `int`.
Call me a hater but I don't like the spiral rule and I like "declaration follows use" even less.
How do you make an std::array of a given type? Wrap the existing type in an extra layer of std::array, we all know this, it makes sense, there's no reasonable alternative. How do you make a C-array of a given type? Oh boy, "prepend the array specifier before the list of existing array specifiers" (actually it's worse because you have to find the right possibly-empty array of existing array specifiers first, just because there's a list of array specifiers somewhere in the type doesn't mean it's the one you should be prepending to).
"Declaration follows use" immediately goes out the window when faced with typedeffed types being used as the base type, or (as mentioned) generics in descendant languages of C. Instead you get "declaration builds up a type by wrapping layers around a core, use breaks down a type layer by layer starting from the outside" (so, necessarily, they mirror each other). C could have worked that way, and it would have made more sense.
"Declaration follows use" is the type level equivalent of taking off your socks before taking off your shoes because that's the order in which you put them on.
> we all know this, it makes sense, there's no reasonable alternative
There absolutely are reasonable alternate ways to represent ordered data that don't involve templates. The way that C does it makes sense in most cases, and if you are looking at something that you cannot understand, you are looking at bad code.
> "Declaration follows use" immediately goes out the window when faced with typedeffed types being used as the base type
Typedefs are an abstraction. If you create a typedef, it is usually because you only want to handle the data as a whole, passing it to helper functions that remove the typedef. Also, declaration of use does not break down with typedefs:
> "Declaration follows use" is the type level equivalent of taking off your socks before taking off your shoes because that's the order in which you put them on.
Please give me an example of some C code where this is the case.
No, I think he means that for any given type, you can wrap it in an array the same way. Your example is demobstating that it even works recursively, but it works in the simple case too by wrapping "int" in an array to get an array of ints. There's no need to jump back and forth between each side when adding new layers (which gets described as a "spiral", but in a single line of code, I'd argue that it's really just jumping back and forth, and that's why it's annoying to people like the parent commenter and I)
I think this is a valid point. I would much prefer if the spiral rule were presented as a helpful mnemonic for remembering C operator precedence rather than something uniquely connected to declarations!
It keeps the parameter and return types inside, makes it obvious that it's a function using the fn keyword (or func or whatever), short and readable.
When you add more parameters you get `fn(int, char -> int)`. That's the only sane way to handle it and it also supports multiple return values if you want them.
Bonus: all type modifiers should be prefix like `?*MyStruct` and control flow should be postfix `task.await.match { ... }`. Every language should either have a pipe operator or let you call any function with method syntax. `x |> f |> g` is better than `g(f(x))`.
This comes up every so often, and while it's sort of almost true and attractive, it isn't actually correct.
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 rule": https://cseweb.ucsd.edu/~gbournou/CSE131/rt_lt.rule.html).
The best summary--and easiest to remember, IMHO--is that variables are declared as they are used.
Want to write an array of function pointers that return a pointer to an array of pointers to int? Well, that's:
array ... -> x[N]
... of function pointers ... -> T (*x[N])()
... that return a pointer ... -> T *(*x[N])()
... to an array ... -> T (*(*x[N])())[M]
... of pointers ... -> T *(*(*x[N])())[M]
... to int ... -> int *(*(*x[N])())[M]
It doesn't make it all that easy to read, but you can at least write the complex types pretty reliably.
(The real answer is of course to just typedef every function pointer type or pointer-to-array and not worry about it anymore.)
Why would you do that? Ignoring for the moment arguments of prototypes and sizes of arrays, read C declarations the way they were designed: “char *a[<whatever>]” means that the expression *a[<whatever>] has type char; “char (*a(<whatever>))[<whatever>]” means that the expression (*a(<whatever>))[<whatever>] has type char; and so on. Then you apply the normal precedence rules for expressions, and in this case only knowing them for the prefix and postfix operators is sufficient. (Hint: all prefix operators have one precedence and all postfix ones another, and you know which one binds tighter if you know what *i++ means.)
I've written some C code recently, and it came to me perhaps the pointer syntax may not be ideal. I'm not sure what the ideal would be, but I think a different notation for usage and declaration could make it less confusion.
In particular I associate '*' (used as *ptr, i.e. content that ptr points to), with content, as opposed to '&' (from &var, address of var), so again '*' means content thing points to. But in declaration, when you declare 'char *ptr', which is a pointer to a char, you clearly can't read it exactly the same way ("char with content of a pointer"? More like, the content of a pointer is char). So maybe another symbol like @ (denoting "is a pointer"), or just the keyword pointer, might make things clearer, so you'd have 'char pointer ptr' (ptr is a pointer to a char, read backwards) or simply 'char @ ptr'. The shorter '@' would be justified when you have multiple pointer e.g. when working with multidimensional arrays (which are often @@@float, something like that). Just an idea that occurred me ;)
(Although I hadn't thought about pcfwik's principle that it's written as used, that makes somewhat more sense to me)*
Edit: Said otherwise, in usage syntax the convention (or at least my way of thinking) may be left-to-right, "content of" or "address of", while in declaration we read right-to-left, "is an int", or "is a pointer", and it would make sense to me that the symbol for "is a pointer" is different than the symbol for "content of"/"address of".
I think the only significant mistake was having both prefix and postfix operators for types. If they all neatly sat on one side there would be no problem.
I thought it was a bit of a miss that C didn't use ^ as the pointer sigil. I mean it's literally pointing. I'm guessing some early terminals didn't have that character on the keyboard.
> I thought it was a bit of a miss that C didn't use ^ as the pointer sigil. I mean it's literally pointing. I'm guessing some early terminals didn't have that character on the keyboard.
That can't be the reason; IIRC Pascal has always used '^' for pointer derefencing (just like git's HEAD^^^)
Which follows an obvious "if modifier of a base type goes to the left of the type, then the operator that uses this modifier goes to the right in the expression". Just like "array of T/[]T" translates into "arr[index]".
There is only one iteration through the spiral in any one declarator unless there are parentheses. This is because it's basically:
[pre] [pre] ... [pre] [core] [post] ... [post]
We have the core of the declarator, usually a name (or empty when omitted). On the left there is a clump of zero or more prefix declarative operators like the pointer *, and on the right postfix ones, like array and function parentheses.
No matter how many there are, you only to around he spiral one time. Let's add the declaration specifiers:
"We declare "core"t to be a this, that and other postfix thing, of this pre, pre of type/quality given by specs."
For instance:
const unsigned int * * * x [][][3]
"Declare x to be a an array of arrays of arrays of 3 pointers to pointers to pointers, to const unsigned int"
But parentheses override the precedence of postfix versus prefix, so that's when the path follows a spiral with multiple loops, for each nesting level:
const unsigned int *(*(*x)[][])[3]
Without parentheses, the precedence is as if implicitly there were these parentheses:
const unsigned int ***(x[][][3])
i.e. postfix "binds tighter" than prefix/unary. That's the whole basis for the spiral: flipping from left to right chasing the sequences of postfix and unary operators, though all the levels of parentheses.
BTW, as a matter of terminology, ISO C does not call type construction punctuators operators; only expressions have operators. In computer science terminology related to programming languages, C declarators are type constructing expressions in which the elements like [] and * are type constructing operators.
Being taught this rule in undergrad really hampered my appreciation of C. As I've said in a previous comment, the real key that unlocked understanding C declarations for me is the mantra "declaration follows use." You declare a variable in C in exactly the same way you would use it: if you know how to use a variable, then you know how to read and write a declaration for it. Once I understood this elegant idea, it became hard to enjoy using statically typed languages that eschew it.
It is explained in more detail at this link: https://eigenstate.org/notes/c-decl
Some more examples:
Where v is an int, w is a pointer, x is an array, y is an array of pointers, z is an array of function pointers, etc.Similarly, typedef is also just a keyword in front of a regular declaration.
Now you can use `bar *` as a function pointer.The entire language works like this.
The way I've learned to read it is
means that `v` is an `int`. means that `*w` is an `int`, meaning `w` is a pointer to an `int`. (note that `◌[]` has higher precedence than `*◌`, so this is `*(y[5])`) means that `*y[5]` is an `int`, so `y[5]` is a pointer to an `int`, meaning `y` is an array of `int` pointers. means that `(*(*kitchensink[5])(int, int))[6]` is an int, so- `*(*kitchensink[5])(int, int)` is an array of `int`.
- `(*kitchensink[5])(int, int)` is a pointer to array of `int`.
- `kitchensink[5]` is a function pointer to a function that takes `(int, int)` and returns a pointer to an array of `int`.
- `kitchensink` is an array of function pointers to functions that take `(int, int)` and return a pointer to an array of `int`.
> int *w;
But some misguided style guides demand the misleading `int* w;`, and then act surprised by `int* w, x`;
Those style guides would also disallow having multiple declarators in a single declaration.
I split the difference and write it "int*w".
(Most style guides tell you to declare one name per line anyway...)
I have seen `int * w` in the real world.
I'm sad now.
Call me a hater but I don't like the spiral rule and I like "declaration follows use" even less.
How do you make an std::array of a given type? Wrap the existing type in an extra layer of std::array, we all know this, it makes sense, there's no reasonable alternative. How do you make a C-array of a given type? Oh boy, "prepend the array specifier before the list of existing array specifiers" (actually it's worse because you have to find the right possibly-empty array of existing array specifiers first, just because there's a list of array specifiers somewhere in the type doesn't mean it's the one you should be prepending to).
"Declaration follows use" immediately goes out the window when faced with typedeffed types being used as the base type, or (as mentioned) generics in descendant languages of C. Instead you get "declaration builds up a type by wrapping layers around a core, use breaks down a type layer by layer starting from the outside" (so, necessarily, they mirror each other). C could have worked that way, and it would have made more sense.
"Declaration follows use" is the type level equivalent of taking off your socks before taking off your shoes because that's the order in which you put them on.
> we all know this, it makes sense, there's no reasonable alternative
There absolutely are reasonable alternate ways to represent ordered data that don't involve templates. The way that C does it makes sense in most cases, and if you are looking at something that you cannot understand, you are looking at bad code.
> "Declaration follows use" immediately goes out the window when faced with typedeffed types being used as the base type
Typedefs are an abstraction. If you create a typedef, it is usually because you only want to handle the data as a whole, passing it to helper functions that remove the typedef. Also, declaration of use does not break down with typedefs:
> "Declaration follows use" is the type level equivalent of taking off your socks before taking off your shoes because that's the order in which you put them on.Please give me an example of some C code where this is the case.
> How do you make an std::array of a given type?
std::array isn't a thing in C, so you don't.
Read the whole post genious, I certainly acknowledge that.
Just for future reference, I believe the correct spelling is genius.
I can get behind deliberately misspelling as "genious" when using it sarcastically.
Or disingenious. :)
Oops, my mistake!
>How do you make an std::array of a given type? Wrap the existing type in an extra layer of std::array, we all know this
huh? where is the extra layer?
>How do you make a C-array of a given type? Oh boy, "prepend the array specifier before the list of existing array specifiers"?
I assume he means multi-dimensional arrays:
But the C-style array is more readable, so I am not sure what the complaint really is about.No, I think he means that for any given type, you can wrap it in an array the same way. Your example is demobstating that it even works recursively, but it works in the simple case too by wrapping "int" in an array to get an array of ints. There's no need to jump back and forth between each side when adding new layers (which gets described as a "spiral", but in a single line of code, I'd argue that it's really just jumping back and forth, and that's why it's annoying to people like the parent commenter and I)
If I would add another array, it would look like:
int c_style_array[2][5][3];
There is also no jumping back and forth. C declarations are also recursively constructed. One can complain about the irregularity of pointers syntax.
The "existing type" in your example is int, the "extra layer" is the array type that "wraps" it
I guess? That's pretty confusing wording, and a bizarre rant if so.
If you explain declarations as following use, you are just moving the spiral parse from declarations to expressions. :)
I think this is a valid point. I would much prefer if the spiral rule were presented as a helpful mnemonic for remembering C operator precedence rather than something uniquely connected to declarations!
Related. Others?
C "clockwise/spiral" rule to understand declarations - https://news.ycombinator.com/item?id=42564861 - Jan 2025 (75 comments)
Clockwise/Spiral Rule - https://news.ycombinator.com/item?id=25494219 - Dec 2020 (16 comments)
The Clockwise/Spiral Rule of C declarations - https://news.ycombinator.com/item?id=12775735 - Oct 2016 (68 comments)
The “Clockwise/Spiral Rule” - https://news.ycombinator.com/item?id=8648287 - Nov 2014 (26 comments)
The Clockwise/Spiral Rule - https://news.ycombinator.com/item?id=6471202 - Sept 2013 (7 comments)
The "Clockwise/Spiral Rule" in C - https://news.ycombinator.com/item?id=5079787 - Jan 2013 (45 comments)
> "str is an array 10 of pointers to char"
Wow, imagine if it was possible to actually use a language like that do declare the type of the variable like that? Something like
or even Just imagine...Yeah, Pascal is very readable, and ^Char is nicer than char* even if inconsistently concise (might expect "pointer to Char").
My ideal syntax for function pointers is:
It keeps the parameter and return types inside, makes it obvious that it's a function using the fn keyword (or func or whatever), short and readable.When you add more parameters you get `fn(int, char -> int)`. That's the only sane way to handle it and it also supports multiple return values if you want them.
Bonus: all type modifiers should be prefix like `?*MyStruct` and control flow should be postfix `task.await.match { ... }`. Every language should either have a pipe operator or let you call any function with method syntax. `x |> f |> g` is better than `g(f(x))`.
> My ideal syntax for function pointers is
this is actually very Kotlin, in Kotlin it'd be `val lambda: (Int, Char) -> Int = { myInt, myChar -> return 69 }`
Zig has also come very close:
> Every language should either have a pipe operator or let you call any function with method syntaxthere is a nicety in Zig that may help: `fn1(p1, ...)` is the same as `fn1.p1()`, so `fn2(fn1(p1))` can be unfolded into `p1.fn1().fn2()`
D simply reads right to left:
This comes up every so often, and while it's sort of almost true and attractive, it isn't actually correct.
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 rule": https://cseweb.ucsd.edu/~gbournou/CSE131/rt_lt.rule.html).
The best summary--and easiest to remember, IMHO--is that variables are declared as they are used.
Want to write an array of function pointers that return a pointer to an array of pointers to int? Well, that's:
It doesn't make it all that easy to read, but you can at least write the complex types pretty reliably.(The real answer is of course to just typedef every function pointer type or pointer-to-array and not worry about it anymore.)
Why would you do that? Ignoring for the moment arguments of prototypes and sizes of arrays, read C declarations the way they were designed: “char *a[<whatever>]” means that the expression *a[<whatever>] has type char; “char (*a(<whatever>))[<whatever>]” means that the expression (*a(<whatever>))[<whatever>] has type char; and so on. Then you apply the normal precedence rules for expressions, and in this case only knowing them for the prefix and postfix operators is sufficient. (Hint: all prefix operators have one precedence and all postfix ones another, and you know which one binds tighter if you know what *i++ means.)
The spiral rule makes no sense, I never got why it got popular.
I've written some C code recently, and it came to me perhaps the pointer syntax may not be ideal. I'm not sure what the ideal would be, but I think a different notation for usage and declaration could make it less confusion.
In particular I associate '*' (used as *ptr, i.e. content that ptr points to), with content, as opposed to '&' (from &var, address of var), so again '*' means content thing points to. But in declaration, when you declare 'char *ptr', which is a pointer to a char, you clearly can't read it exactly the same way ("char with content of a pointer"? More like, the content of a pointer is char). So maybe another symbol like @ (denoting "is a pointer"), or just the keyword pointer, might make things clearer, so you'd have 'char pointer ptr' (ptr is a pointer to a char, read backwards) or simply 'char @ ptr'. The shorter '@' would be justified when you have multiple pointer e.g. when working with multidimensional arrays (which are often @@@float, something like that). Just an idea that occurred me ;)
(Although I hadn't thought about pcfwik's principle that it's written as used, that makes somewhat more sense to me)*
Edit: Said otherwise, in usage syntax the convention (or at least my way of thinking) may be left-to-right, "content of" or "address of", while in declaration we read right-to-left, "is an int", or "is a pointer", and it would make sense to me that the symbol for "is a pointer" is different than the symbol for "content of"/"address of".
The reading of `char *p` is: The following things are `char`: `*p`.
I think the only significant mistake was having both prefix and postfix operators for types. If they all neatly sat on one side there would be no problem.
I thought it was a bit of a miss that C didn't use ^ as the pointer sigil. I mean it's literally pointing. I'm guessing some early terminals didn't have that character on the keyboard.
> I thought it was a bit of a miss that C didn't use ^ as the pointer sigil. I mean it's literally pointing. I'm guessing some early terminals didn't have that character on the keyboard.
That can't be the reason; IIRC Pascal has always used '^' for pointer derefencing (just like git's HEAD^^^)
i find Zig does it fairly well. there is also no ambiguity between pointer and multiply.
Yeah, they took it from Pascal:
Which follows an obvious "if modifier of a base type goes to the left of the type, then the operator that uses this modifier goes to the right in the expression". Just like "array of T/[]T" translates into "arr[index]".Borrow from the late 1990s upstart GC languages: Pointer<Type>.
This is useful if you're far from the internet. Here's a web site that translates the gibberish to English or vice versa:
https://cdecl.org/
Or
on Linux.There is only one iteration through the spiral in any one declarator unless there are parentheses. This is because it's basically:
We have the core of the declarator, usually a name (or empty when omitted). On the left there is a clump of zero or more prefix declarative operators like the pointer *, and on the right postfix ones, like array and function parentheses.No matter how many there are, you only to around he spiral one time. Let's add the declaration specifiers:
"We declare "core" to be ..." "We declare "core" to be a this, that and other postfix thing ..." "We declare "core"t to be a this, that and other postfix thing, of this pre, pre ... "We declare "core"t to be a this, that and other postfix thing, of this pre, pre of type/quality given by specs."For instance:
"Declare x to be a an array of arrays of arrays of 3 pointers to pointers to pointers, to const unsigned int"But parentheses override the precedence of postfix versus prefix, so that's when the path follows a spiral with multiple loops, for each nesting level:
Without parentheses, the precedence is as if implicitly there were these parentheses: i.e. postfix "binds tighter" than prefix/unary. That's the whole basis for the spiral: flipping from left to right chasing the sequences of postfix and unary operators, though all the levels of parentheses.BTW, as a matter of terminology, ISO C does not call type construction punctuators operators; only expressions have operators. In computer science terminology related to programming languages, C declarators are type constructing expressions in which the elements like [] and * are type constructing operators.
This is why I like python.
str is a duck.