41–50 of 72 posts
(())()(()())(())
Way 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…
What happened to the const in the second example?
Earlier quoted context omitted.
What happened to the const in the second example?
Yeah, I think they confused const * with * const
Just don't make complex declarations in C, it's almost never useful and won't help anyone out. It'll confuse people and make your code write-only. Just put in a couple extra lines of code somewhere if you have to. It won't be the end of the world.
It'll certainly confuse people, but only those who aren't qualified to be doing anything with the code anyway. "complex" is subjective. It reminds me of stupid "rules" like "don't use the ternary operator", "every function must be less than 20 lines" (I am not exaggerating --- this was on a Java project, however); and you could easily extend that to "every statement must have a maximum of one operator", "you must not…
And people wonder why there are so many broken C programs out there...
Just don't make complex declarations in C, it's almost never useful and won't help anyone out. It'll confuse people and make your code write-only. Just put in a couple extra lines of code somewhere if you have to. It won't be the end of the world.
It'll certainly confuse people, but only those who aren't qualified to be doing anything with the code anyway. "complex" is subjective. It reminds me of stupid "rules" like "don't use the ternary operator", "every function must be less than 20 lines" (I am not exaggerating --- this was on a Java project, however); and you could easily extend that to "every statement must have a maximum of one operator", "you must not…
If the complexity can be avoided, why not avoid it. Removing complexity is not the same as dumb-downing code. It will improve readability and maintainability.
This mindset is defintitely applicable to declaration as well as code construct.
edit: clarity.
What makes me wonder is why C ended up with such a syntax. That is, its contemporary, Pascal, has a very straightforward, unambiguous syntax.
The type syntax exactly matches the expression syntax used to destruct values of the type. It is very intuitive once you realize this. The alternative would be for the type syntax to mirror the expression syntax used to construct values of the type. Functional languages tend to do this, particularly ones which prefer pattern matching over destructors.
Earlier quoted context omitted.
I am not familiar with Go, and have heard many praises of its declaration syntax, but is its dereference operator postfix? That would make sense in such a case. On the other hand, IMHO the whole "make declarations read left-to-right" idea is misguided --- plenty of other constructs exist in programming languages which simply can't be read left-to-right, but are nested according to precedence. I mean, you might as wel…
Go's defererence operator `*` is prefix, like in C. The point here is that type declarations are regular to read, and those tend to be the tricky ones. Expressions tend not to be so difficult, and are more commonly factored if they become complex. For various reason, type declarations are not so practically factorable.
Declaring `v * T` means we can write `* v` as an expression, so the use of token * is synchronized for both these uses, but I must vocalize the * in my head differently:
`*T` vocalizes as "pointer to something of type T"
`*v` vocalizes as "that pointed to by variable v"
`&v` vocalizes as "pointer to variable v"
Earlier quoted context omitted.
Yeah, I think they confused const * with * const
Nope, * const means that the identifier (i.e. thing to the right of the star) is const. That is, in this example, the symbol "bar" is const, not anything that it points to. So once you dereference it, the const no longer matters.