[pcfwik]

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

[IronFox05]

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.

[clifflocked]

> 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:

    typedef char *(*fn)(int, char *);
    fn my_fn;

    char *s = (*my_fn)(0, ""); // Proper use

> "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.

[jstanley]

> How do you make an std::array of a given type?

std::array isn't a thing in C, so you don't.

[stackghost]

>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<int, 5> 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};

[uecker]

I assume he means multi-dimensional arrays:

    std::array<std::array<int, 3>, 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.

[saghm]

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)

[uecker]

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.

[saghm]

Yes, if you only use arrays, then it doesn't make things confusing. The point they were making (as I understand it) is that putting a pointer inside std::array doesn't change the way you have to read it, which is not the case for C arrays.

[saghm]

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

[stackghost]

I guess? That's pretty confusing wording, and a bizarre rant if so.

[saghm]

I don't find it confusing or bizarre, but those are both subjective, so I can't say that you're wrong.

[nitrix]

Some more examples:

  int v, *w, x[5], *y[5], (*z[5])(int, int);

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.

  int foo[5];
  typedef int foo[5];

  int bar(void);
  typedef int bar(void);

Now you can use `bar *` as a function pointer.

The entire language works like this.

[arjvik]

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))[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`.

[kps]

> int *w;

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

[uecker]

Those style guides would also disallow having multiple declarators in a single declaration.

[tom_]

I split the difference and write it "int*w".

(Most style guides tell you to declare one name per line anyway...)

[kps]

I have seen `int * w` in the real world.

I'm sad now.

[kazinator]

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

[pcfwik]

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!