6 ms·

And how would you read the following? int* i, j; C declarations simply are not "first the type, then the variable"...

lionkor 2y ago
you would read it, spot the problem, and fix it to make it two lines. if you dont have space for that one line, switch back to punchcards
jandrese 2y ago
IMHO the way comma behaves when declaring multiple variables of the same type was a mistake from day one. The sort of thing that only sticks around because it would break too much existing code to fix it. If I were in charge I'd declare the syntax deprecated in the next version of C and introduce a new character, maybe | that would do the same thing except it would propagate the pointer as you would expect. In my code I never use it. Every variable gets its own line. You might think this would blow up the declarations, but in practice it's not a problem, especially in modern C where you can move declarations down to where they're used instead of stuffing them all up at the top of the function.
- jstimpfle 2y ago
  The only "type" thing about the declaration above is "int", and that does get applied to all the comma-separated expressions -- so in that way the comma acts totally reasonable. People think that "int *x;" means "declare x as a pointer-to-int" but really it means "declare x such that *x (it's a code expression) is of type int." So it's a really roundabout way to say that x is a "pointer to x" while that concept of "pointer to" isn't even in the language syntax.
  - jandrese 2y ago
    Which makes it even worse because it is inconsistent in real world use. "long" is propagated through the comma, but * is not.
    - jstimpfle 2y ago
      It's not inconsistent. There are two things in a declaration: a type (here int) and an expression (here *x). If you add commas you can have multiple of the latter. That's it. Stop thinking of the star as part of the type, it isn't. Leave it with the expression to the right, and thinks make sense . It's why I always cringe when I see int* x; as opposed to int *x; There is a reason why K&R do it that way.
      - jandrese 2y ago
        The idea that the * isn't part of the type has always felt completely wrong to me. The entire concept of an expression modifying the type doesn't provide any benefit that I can see. The only thing the expression should be doing is giving you the chance to assign the name to the new variable you're creating. Once you define the type, which might be a pointer or not, it should be fixed. I get that this is a pretty fundamental disagreement between me and Knuth & Richie, but I think history has shown that this idea of splitting exactly one aspect of the type (if the variable is direct or a pointer) was a mistake. It's been the cause of a lot of bugs and the cases where you want to define both direct and indirect types on the same line basically don't exist. For clarity you should split those definitions up regardless of what the syntax allows. There are basically no cases where you should be writing the following code even if it is technically correct: int *pointer, direct;
        jstimpfle 2y ago
        I never use comma, I always define one variable per line. Much easier to edit and read. However, the way it works is certainly not inconsistent. As to your other concerns, it makes perfect sense. int WHATEVER; read as "WHATEVER is an int" and you can work backwards from there. There is no more type syntax than that. The thing is, it's much easier to look at stuff this way since otherwise you'll have to shift back and forth between 2 different syntaxes (types and expressions) all the time. I've been looking a lot for a better more algebraic syntax too. All syntaxes I've found have lost on two axes _in the common and simple cases_ - low cognitive overhead - terseness Yes, the principle of declaration follows usage is already stretched to its limit, and C++ has certainly overstretched it. But still for the bread-and-butter use cases, the "better" syntaxes seem to always lose on those 2 axes.

you would read it, spot the problem, and fix it to make it two lines. if you dont have space for that one line, switch back to punchcards

jandrese 2y ago

IMHO the way comma behaves when declaring multiple variables of the same type was a mistake from day one. The sort of thing that only sticks around because it would break too much existing code to fix it. If I were in charge I'd declare the syntax deprecated in the next version of C and introduce a new character, maybe | that would do the same thing except it would propagate the pointer as you would expect. In my code I never use it. Every variable gets its own line. You might think this would blow up the declarations, but in practice it's not a problem, especially in modern C where you can move declarations down to where they're used instead of stuffing them all up at the top of the function.

jstimpfle 2y ago
The only "type" thing about the declaration above is "int", and that does get applied to all the comma-separated expressions -- so in that way the comma acts totally reasonable. People think that "int *x;" means "declare x as a pointer-to-int" but really it means "declare x such that *x (it's a code expression) is of type int." So it's a really roundabout way to say that x is a "pointer to x" while that concept of "pointer to" isn't even in the language syntax.
- jandrese 2y ago
  Which makes it even worse because it is inconsistent in real world use. "long" is propagated through the comma, but * is not.
  - jstimpfle 2y ago
    It's not inconsistent. There are two things in a declaration: a type (here int) and an expression (here *x). If you add commas you can have multiple of the latter. That's it. Stop thinking of the star as part of the type, it isn't. Leave it with the expression to the right, and thinks make sense . It's why I always cringe when I see int* x; as opposed to int *x; There is a reason why K&R do it that way.
    - jandrese 2y ago
      The idea that the * isn't part of the type has always felt completely wrong to me. The entire concept of an expression modifying the type doesn't provide any benefit that I can see. The only thing the expression should be doing is giving you the chance to assign the name to the new variable you're creating. Once you define the type, which might be a pointer or not, it should be fixed. I get that this is a pretty fundamental disagreement between me and Knuth & Richie, but I think history has shown that this idea of splitting exactly one aspect of the type (if the variable is direct or a pointer) was a mistake. It's been the cause of a lot of bugs and the cases where you want to define both direct and indirect types on the same line basically don't exist. For clarity you should split those definitions up regardless of what the syntax allows. There are basically no cases where you should be writing the following code even if it is technically correct: int *pointer, direct;
      - jstimpfle 2y ago
        I never use comma, I always define one variable per line. Much easier to edit and read. However, the way it works is certainly not inconsistent. As to your other concerns, it makes perfect sense. int WHATEVER; read as "WHATEVER is an int" and you can work backwards from there. There is no more type syntax than that. The thing is, it's much easier to look at stuff this way since otherwise you'll have to shift back and forth between 2 different syntaxes (types and expressions) all the time. I've been looking a lot for a better more algebraic syntax too. All syntaxes I've found have lost on two axes _in the common and simple cases_ - low cognitive overhead - terseness Yes, the principle of declaration follows usage is already stretched to its limit, and C++ has certainly overstretched it. But still for the bread-and-butter use cases, the "better" syntaxes seem to always lose on those 2 axes.