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

The "Clockwise/Spiral Rule" in C

c-faq.com

Post reply on HN
Print view View original

21–30 of 49 posts

Re: The "Clockwise/Spiral Rule" in C

#21

Post by daeken »

tptacek wrote: post #6

In practice, nobody uses a "clockwise/spiral rule" to read C declarations; they typedef complex declarations into bite-sized components. C declarations are hardest to understand when they involve (1) "arrays"† of "arrays" of "arrays", (2) function pointers, and (3) multiple layers of indirection. In systems and networking code and in most application code, (1) "multi-level arrays" are uncommon, and they're uncommon i…

I make a rule of always typedefing function pointer types. I've never seen a single case where it didn't make things cleaner and more readable, not to mention that it's significantly easier to change the declarations in the future, since you rarely have a single place where you define and use a function pointer.

Re: The "Clockwise/Spiral Rule" in C

#23

Post by tedunangst »

revelation wrote: post #18
tedunangst wrote: post #15

Earlier quoted context omitted.

I think it works if you treat all the [] as a single token. foo is a 3x4 two dimensional array of pointers to int.

But its not, there are no two dimensional arrays. There are arrays of arrays.

The sizeof operator begs to differ.

Re: The "Clockwise/Spiral Rule" in C

#24

Post by lomendil »

I can't imagine using this for real. Perception is so much more parallel than that. If I see

  char *(*fp)(int)
I see that it matches the pattern

  returntype *(*function)(args)
It's the "* (* )()" that one sees all at once, and that signifies "this is a function pointer".

This actually reminds me of some research where kids are asked to trace the direction of interlocked gears. They start by looking at each one, but soon they move to more general strategies. Edit - this is the one, in case anyone is curious: Dixon, J. A., & Bangert, A. S. (2002). The prehistory of discovery: precursors of representational change in solving gear system problems. Developmental Psychology, 38(6), 918.

Re: The "Clockwise/Spiral Rule" in C

#25

Post by tedunangst »

stephencanon wrote: post #17
tedunangst wrote: post #15

Earlier quoted context omitted.

I think it works if you treat all the [] as a single token. foo is a 3x4 two dimensional array of pointers to int.

You can construct a rule along those lines that would work (though just taking all the [] at once doesn't suffice), but it ends up being precisely equivalent to the right-left rule, so I don't really see the point.

I think the point is that the spiral rule is just a way to remember/implement the right left rule.

Re: The "Clockwise/Spiral Rule" in C

#26

Post by DannoHung »

tptacek wrote: post #6

In practice, nobody uses a "clockwise/spiral rule" to read C declarations; they typedef complex declarations into bite-sized components. C declarations are hardest to understand when they involve (1) "arrays"† of "arrays" of "arrays", (2) function pointers, and (3) multiple layers of indirection. In systems and networking code and in most application code, (1) "multi-level arrays" are uncommon, and they're uncommon i…

I like types. I do have a question though: Why do you call it "sig_t" as opposed to "sig_h" or something. Based on its positional appearance, it's pretty clear that it's a type. Or does t stand for something else?

Re: The "Clockwise/Spiral Rule" in C

#28

Post by wrl »

DannoHung wrote: post #26
tptacek wrote: post #6

In practice, nobody uses a "clockwise/spiral rule" to read C declarations; they typedef complex declarations into bite-sized components. C declarations are hardest to understand when they involve (1) "arrays"† of "arrays" of "arrays", (2) function pointers, and (3) multiple layers of indirection. In systems and networking code and in most application code, (1) "multi-level arrays" are uncommon, and they're uncommon i…

I like types. I do have a question though: Why do you call it "sig_t" as opposed to "sig_h" or something. Based on its positional appearance, it's pretty clear that it's a type. Or does t stand for something else?

It's a POSIX convention to indicate that it's a typedef.

Re: The "Clockwise/Spiral Rule" in C

#29

Post by stephencanon »

wrl wrote: post #28
DannoHung wrote: post #26

Earlier quoted context omitted.

I like types. I do have a question though: Why do you call it "sig_t" as opposed to "sig_h" or something. Based on its positional appearance, it's pretty clear that it's a type. Or does t stand for something else?

It's a POSIX convention to indicate that it's a typedef.

User code built against POSIX should never use the _t suffix; POSIX explicitly puts *_t into the reserved namespace (http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh...), meaning that future revisions may add arbitrary type names of that form, which will break your code if you use the same name and include POSIX headers.

Re: The "Clockwise/Spiral Rule" in C

#30

Post by tptacek »

stephencanon wrote: post #29
wrl wrote: post #28

Earlier quoted context omitted.

It's a POSIX convention to indicate that it's a typedef.

User code built against POSIX should never use the _t suffix; POSIX explicitly puts *_t into the reserved namespace ( http://pubs.opengroup.org/onlinepubs/007904975/functions/xsh... ), meaning that future revisions may add arbitrary type names of that form, which will break your code if you use the same name and include POSIX headers.

Thbthbthbthbthbththbthtbhtbhthbt! I say to POSIX. This convention is practically universal.
Post reply on HN