Live data from Hacker News

Clockwise/Spiral Rule (1994)

c-faq.com

31–40 of 59 posts

Re: Clockwise/Spiral Rule (1994)

#31

Earlier quoted context omitted.

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 beca…

>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? std::array array_of_ints = { 1, 2, 3, 4, 5 }; >How do you make a C-array of a given type? Oh boy, "prepend the array specifier before the list of existing array specifiers" ? int c_style_array[5] = {2, 3, 5, 7, 11};

The "existing type" in your example is int, the "extra layer" is the array type that "wraps" it

Re: Clockwise/Spiral Rule (1994)

#32
post #4

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 bec…

If you explain declarations as following use, you are just moving the spiral parse from declarations to expressions. :)

Re: Clockwise/Spiral Rule (1994)

#34
post #26

Earlier quoted context omitted.

>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? std::array array_of_ints = { 1, 2, 3, 4, 5 }; >How do you make a C-array of a given type? Oh boy, "prepend the array specifier before the list of existing array specifiers" ? int c_style_array[5] = {2, 3, 5, 7, 11};

I assume he means multi-dimensional arrays: std::array , 5> array_of_ints; int c_style_array[5][3]; 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)

Re: Clockwise/Spiral Rule (1994)

#35
post #31

Earlier quoted context omitted.

>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? std::array array_of_ints = { 1, 2, 3, 4, 5 }; >How do you make a C-array of a given type? Oh boy, "prepend the array specifier before the list of existing array specifiers" ? int c_style_array[5] = {2, 3, 5, 7, 11};

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.

Re: Clockwise/Spiral Rule (1994)

#36
post #21
post #17

Earlier quoted context omitted.

The way I've learned to read it is int v; means that `v` is an `int`. int *w; 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))[…

> int *w; But some misguided style guides demand the misleading `int* w;`, and then act surprised by `int* w, x`;

[deleted]

Re: Clockwise/Spiral Rule (1994)

#37

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 decl…

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.

Re: Clockwise/Spiral Rule (1994)

#38
My ideal syntax for function pointers is:

  fn signal(signum: int, fp: fn(int -> void)) -> fn(int -> void)
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))`.

Re: Clockwise/Spiral Rule (1994)

#39
post #4

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 bec…

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!
Post reply on HN