This is the reason why golang declares the identifier before the type and the return value at the after the function parameters. This allows parsing any declaration from left to right.
The Clockwise/Spiral Rule of C declarations
61–70 of 72 posts
Re: The Clockwise/Spiral Rule of C declarations
#62One problem with the web is that it will remember wrong information just as well as it will remember correct information.
Re: The Clockwise/Spiral Rule of C declarations
#63Once I tried to figure out how to parse complex C declarations just by reading the specification (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf), that is, without consulting guides for layman like this. But I gave up. I looked at what seemed a BNF-like description of the C grammar but I had no idea what it tells about the parsing rules. So I ended up using this guide: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html With this I managed to implement an imitation of cdecl.
Re: The Clockwise/Spiral Rule of C declarations
#64Or, as the book Expert C Programming says, declarations in C are read boustrophedonically.
Re: The Clockwise/Spiral Rule of C declarations
#65I read a paper somewhere from dennis ritchie, where he explained the development of C language, the pros and cons; and in there he mentioned that reading complex declarations is a problem in C, he said that if we had placed the * operator to the left of the type it was qualifying then it would have been easier to write and understand more complex declarations.
(PS. Golang has the right idea, since its developed by the guys who contributed to C)...
Re: The Clockwise/Spiral Rule of C declarations
#66Or, as the book Expert C Programming says, declarations in C are read boustrophedonically.
[deleted]
Re: The Clockwise/Spiral Rule of C declarations
#67I read a paper somewhere from dennis ritchie, where he explained the development of C language, the pros and cons; and in there he mentioned that reading complex declarations is a problem in C, he said that if we had placed the * operator to the left of the type it was qualifying then it would have been easier to write and understand more complex declarations. (PS. Golang has the right idea, since its developed by th…
Go fixes a lot of C language design bugs, and the only cost you pay is (sometimes important) garbage collection and extreme memory layout control.
Re: The Clockwise/Spiral Rule of C declarations
#68The first red flag is that the rule says "clockwise" where there s clearly to way to distinguish clocwise from anticlockwise inside the code. Only the completely arbitrary choice of up/down direction of the drawing affects clockwiseness.
It's been 20years(!) Why is this incorrect advise still up at c-faq?
Re: The Clockwise/Spiral Rule of C declarations
#69Way simpler: from inside out, read any subpart of the type as an expression. (Arrays have precedence over pointers, as usual.) The type that remains is that expression's type. So e.g. given the type: const char *foo[][50] the following expressions have the following types: foo -> const char *[][50] foo[0] -> const char * [50] foo[0][0] -> const char * *foo[0][0] -> const char Another example: int (*const bar)[restric…
This would make a great CLI tool!
Re: The Clockwise/Spiral Rule of C declarations
#70I read a paper somewhere from dennis ritchie, where he explained the development of C language, the pros and cons; and in there he mentioned that reading complex declarations is a problem in C, he said that if we had placed the * operator to the left of the type it was qualifying then it would have been easier to write and understand more complex declarations. (PS. Golang has the right idea, since its developed by th…
Go fixes a lot of C language design bugs, and the only cost you pay is (sometimes important) garbage collection and extreme memory layout control.
I guess thats a given with the amount of ease and fast prototyping that it provides, it had to have taken a lot of decisions beforehand for you...