3 ms·

My auto-formatter always changes it like that and I just don't understand why `char foo` is better than `char foo`. I consider `char*` to be the type of `foo

My auto-formatter always changes it like that and I just don't understand why `char *foo` is better than `char* foo`. I consider `char*` to be the type of `foo`. What's the rationale of having `char *foo`?

onre 2y ago
Dunno how this is supposed to be worded, but it's because the "pointerhood" is tied to the variable being declared, not the type itself. This becomes obvious when you declare multiple variables at once. char* cat, dog; /* one char pointer, one char */ char *cat, *dog; /* two char pointers */
- teo_zero 2y ago
  Right. It would be nice if C allowed types and variables to be separated, we could even defines arrays like this: char[8] buffer; Alas, it's not the syntax Dennis Ritchie settled upon.
  - cb321 2y ago
    The trade-off is one vs. two operator sub-syntaxes or in other words "sub-syntax economy". As it is, C has just one operator expression syntax (and one set of operator precedences/associativities). The "forward applicative" expression syntax is "reused" in the "backward" or "inverse" type declarations.
- kevin_thibedeau 2y ago
  The minor problem is that a typedef pointer breaks this pattern: typedef foo * FooP; FooP a, b; // Both are pointers Pointer typedefs are misguided but there is no denying that C is inconsistent on whether the '*' is part of the type or not.
eqvinox 2y ago
It's purely cultural. "char* foo" or "char * foo" does make more sense than "char *foo". But culture is a very strong and useful thing; if it "looks weird", that will create issues in people's brain when thinking about the code. Also, case in point: how do you format "char * const foo"?
- cb321 2y ago
  Redundant cues are also strong. So, for example, C is largely whitespace-insensitive and operator precedence can matter a lot. Consider "x+y*z". If you always spaced this "x+y * z" it would be the same to the parser but less clear to a human than spacing it "x + y*z" where you have used whitespace as a redundant cue to operator precedence. Similarly, what makes C type declarators tricky for many is their "inverse nature" - "char *foo" means, applying the operator "*" to the identifier "foo" yields a base type "char". So, the "char* foo" form is literally creating a cue in the opposite direction of operator precedence just like "x+y * z" would. For just one indirection it's no big deal, but for things like "char *foo[]" and beyond it becomes more important. So, the "mis"-spacing "char* foo" sets people up for later conceptual failure. This is in addition to the above point by @onre about multiple identifiers and @anacrolix's initial rather, ahem, pithy take. There is also another "where would ()s be redundant/unneeded" rationale (though this largely recapitulates the 2nd paragraph here). If you are looking for a catchphrase then maybe it could be "Don't space-against-syntax".
  - uecker 2y ago
    I do not think this analysis is correct. "char *foo" is not a cue in the wrong direction, it indicates that in "char *foo, bar" only foo is a pointer. Whether the syntax for declarations in C is a good or idea or not is a different question, but it is not misleading in the same way "x+y * z" is.
    - cb321 2y ago
      You seem to have misinterpreted my comment since we agree that the "no-space-before 'foo' way" is truer to the syntax, and to repeat myself, I had said "char* foo" is the bad cue and even mentioned @onre's multiple identifiers supporting point (which you reiterate). It can be hard to see whitespace on HN comments, though unless you do the 4space indents to get a monospaced font. You can in-page search, though. The only difference with the spacing against syntax in "x+y * z" is that there are fewer type-relevant operators (e.g. '+' does not work in a type expression). One does NOT hear people advocating for more space around '*' than '+' (though I have sometimes heard "equal space"). Your non-disagreement has not persuaded me that this is a bad way to explain the problem, although I agree I could cut down on the double negatives. :-) { Even grade school kids have some sense of precedence of '+' & '*' which is so broadly adopted that even hand calculators do it. } "How misleading" spacing against syntax can be is admittedly more subjective. I think whitespace can really matter to human readers. There are many other examples. gcc added -Wmisleading-indentation a while back. Off-side rule languages like Python embrace things that sometimes prevent that problem. The Nim compiler was once sensitive to exactly this kind of operator spacing where it would parse "x+y * z" { space around '*' } as "(x+y)*z" in an attempt to have the compiler "Do what I mean".

My auto-formatter always changes it like that and I just don't understand why `char *foo` is better than `char* foo`. I consider `char*` to be the type of `foo

onre 2y ago

Dunno how this is supposed to be worded, but it's because the "pointerhood" is tied to the variable being declared, not the type itself. This becomes obvious when you declare multiple variables at once. char* cat, dog; /* one char pointer, one char */ char *cat, *dog; /* two char pointers */

teo_zero 2y ago
Right. It would be nice if C allowed types and variables to be separated, we could even defines arrays like this: char[8] buffer; Alas, it's not the syntax Dennis Ritchie settled upon.
- cb321 2y ago
  The trade-off is one vs. two operator sub-syntaxes or in other words "sub-syntax economy". As it is, C has just one operator expression syntax (and one set of operator precedences/associativities). The "forward applicative" expression syntax is "reused" in the "backward" or "inverse" type declarations.
kevin_thibedeau 2y ago
The minor problem is that a typedef pointer breaks this pattern: typedef foo * FooP; FooP a, b; // Both are pointers Pointer typedefs are misguided but there is no denying that C is inconsistent on whether the '*' is part of the type or not.

eqvinox 2y ago

It's purely cultural. "char* foo" or "char * foo" does make more sense than "char *foo". But culture is a very strong and useful thing; if it "looks weird", that will create issues in people's brain when thinking about the code. Also, case in point: how do you format "char * const foo"?

cb321 2y ago
Redundant cues are also strong. So, for example, C is largely whitespace-insensitive and operator precedence can matter a lot. Consider "x+y*z". If you always spaced this "x+y * z" it would be the same to the parser but less clear to a human than spacing it "x + y*z" where you have used whitespace as a redundant cue to operator precedence. Similarly, what makes C type declarators tricky for many is their "inverse nature" - "char *foo" means, applying the operator "*" to the identifier "foo" yields a base type "char". So, the "char* foo" form is literally creating a cue in the opposite direction of operator precedence just like "x+y * z" would. For just one indirection it's no big deal, but for things like "char *foo[]" and beyond it becomes more important. So, the "mis"-spacing "char* foo" sets people up for later conceptual failure. This is in addition to the above point by @onre about multiple identifiers and @anacrolix's initial rather, ahem, pithy take. There is also another "where would ()s be redundant/unneeded" rationale (though this largely recapitulates the 2nd paragraph here). If you are looking for a catchphrase then maybe it could be "Don't space-against-syntax".
- uecker 2y ago
  I do not think this analysis is correct. "char *foo" is not a cue in the wrong direction, it indicates that in "char *foo, bar" only foo is a pointer. Whether the syntax for declarations in C is a good or idea or not is a different question, but it is not misleading in the same way "x+y * z" is.
  - cb321 2y ago
    You seem to have misinterpreted my comment since we agree that the "no-space-before 'foo' way" is truer to the syntax, and to repeat myself, I had said "char* foo" is the bad cue and even mentioned @onre's multiple identifiers supporting point (which you reiterate). It can be hard to see whitespace on HN comments, though unless you do the 4space indents to get a monospaced font. You can in-page search, though. The only difference with the spacing against syntax in "x+y * z" is that there are fewer type-relevant operators (e.g. '+' does not work in a type expression). One does NOT hear people advocating for more space around '*' than '+' (though I have sometimes heard "equal space"). Your non-disagreement has not persuaded me that this is a bad way to explain the problem, although I agree I could cut down on the double negatives. :-) { Even grade school kids have some sense of precedence of '+' & '*' which is so broadly adopted that even hand calculators do it. } "How misleading" spacing against syntax can be is admittedly more subjective. I think whitespace can really matter to human readers. There are many other examples. gcc added -Wmisleading-indentation a while back. Off-side rule languages like Python embrace things that sometimes prevent that problem. The Nim compiler was once sensitive to exactly this kind of operator spacing where it would parse "x+y * z" { space around '*' } as "(x+y)*z" in an attempt to have the compiler "Do what I mean".