Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Clockwise/Spiral Rule (1994)

c-faq.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: Clockwise/Spiral Rule (1994)

#11

Post by gnramires »

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

Re: Clockwise/Spiral Rule (1994)

#12

Post by dnautics »

gnramires wrote: post #11

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 find Zig does it fairly well. there is also no ambiguity between pointer and multiply.

Re: Clockwise/Spiral Rule (1994)

#13

Post by jandrese »

gnramires wrote: post #11

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

Re: Clockwise/Spiral Rule (1994)

#14

Post by IronFox05 »

pcfwik wrote: 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…

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.

Re: Clockwise/Spiral Rule (1994)

#15

Post by jstanley »

IronFox05 wrote: post #14
pcfwik wrote: 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…

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?

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

Re: Clockwise/Spiral Rule (1994)

#16

Post by IronFox05 »

jstanley wrote: post #15
IronFox05 wrote: post #14

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? std::array isn't a thing in C, so you don't.

[flagged]

Re: Clockwise/Spiral Rule (1994)

#17

Post by arjvik »

nitrix wrote: post #10
pcfwik wrote: 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…

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.

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

Re: Clockwise/Spiral Rule (1994)

#18

Post by Joker_vD »

dnautics wrote: post #12
gnramires wrote: post #11

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 find Zig does it fairly well. there is also no ambiguity between pointer and multiply.

Yeah, they took it from Pascal:

    var p: ^integer, i: integer;

    p := @i;
    p^ := 42;
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]".

Re: Clockwise/Spiral Rule (1994)

#19

Post by delta_p_delta_x »

gnramires wrote: post #11

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…

Borrow from the late 1990s upstart GC languages: Pointer.
Post reply on HN