Live data from Hacker News

The "Clockwise/Spiral Rule" in C

c-faq.com

31–40 of 49 posts

Re: The "Clockwise/Spiral Rule" in C

#31
post #30

Earlier quoted context omitted.

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.

Just so long as I don't see you filing any bug reports when POSIX changes a header and your code stops compiling. =)

Re: The "Clockwise/Spiral Rule" in C

#32

Earlier quoted context omitted.

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

The sizeof operator begs to differ.

How does it differ? It just gives the size of the whole object -- that doesn't mean it's not an array of arrays...

Re: The "Clockwise/Spiral Rule" in C

#33
post #32

Earlier quoted context omitted.

The sizeof operator begs to differ.

How does it differ? It just gives the size of the whole object -- that doesn't mean it's not an array of arrays...

Hmm, I'm not sure what to say. A two dimensional array is an array of arrays. I'm objecting to the idea that two dimensional arrays are some mythical construction.

For instance, the only way to construct a ragged array is with pointers, and then sizeof doesn't "work" to give the complete size. Also, the [][] syntax is one of the places where pointers and arrays are less equivalent than usual. You can't pass a [][] array via star star.

Re: The "Clockwise/Spiral Rule" in C

#34
post #30

Earlier quoted context omitted.

Thbthbthbthbthbththbthtbhtbhthbt! I say to POSIX. This convention is practically universal.

Just so long as I don't see you filing any bug reports when POSIX changes a header and your code stops compiling. =)

That's why I use *__t (two underscores).

Re: The "Clockwise/Spiral Rule" in C

#35

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

But before the kids could use general strategies, they had to work out the details.

You're right, the spiral rule is probably unwieldy in practice. But until a programmer can recognize the patterns, the rule can be used as a learning aid.

Re: The "Clockwise/Spiral Rule" in C

#36
Great post. But it's lack of explanations in type qualifiers and storage specifiers. C declaration is not easy for beginners but surely is one of the most important subjects towards optimisations. Correct usage of const and restrict keywords let compiler optimise your code super fast for free. Check my post for example usage of type qualifiers and how the syntax is structured in C: http://www.idryman.org/blog/2012/10/29/type-qualifiers/

Re: The "Clockwise/Spiral Rule" in C

#37

The "spiral rule" makes for pretty pictures, but unfortunately it isn't correct. One simple example: int *foo[3][4]; The spiral rule would have us read this as "foo is an array [3] of pointers to array [4] of int". What it actually is is "foo is an array [3] of arrays [4] of pointers to int". The correct rule* for parsing declarations is "Start from the thing being declared, and read right until you hit a closing par…

[deleted]

Re: The "Clockwise/Spiral Rule" in C

#39

This is why I like S-Expressions

S-expressions don't declare types, though. A sexp grammar for the same thing would be basically isomorphic to a fully-parenthesized C type expression.

C has some glitches: the fact that the pointer type decoration goes on the left while the array decoration goes on the right is one. The precedence rule that requires parentheses for function pointers is unfortunate. And the putting the decoration on the variable and not the type is just simply a bug IMHO.

But the complexity here is inherent. Complicated types require complicated expressions no matter what grammar you use.

Post reply on HN