4 ms·

The parent says it is "cosmetic", not technical. The parent, being someone who wrote C daily for 25 years, knows what the syntax allows and that it isn't necess

The parent says it is "cosmetic", not technical. The parent, being someone who wrote C daily for 25 years, knows what the syntax allows and that it isn't necessary. A constant pointer to a constant pointer to a constant integer should be written "int const * const * const x" because there's only one other way, "const int * const * const x," which is inconsistent, ugly and potentially confusing.

kazinator 7y ago
It's bad cosmetic. The predominant style is "const int", following the English adjective before noun.
- deleted 7y ago
  [deleted]
- kccqzy 7y ago
  It depends on the perspective. To me and in the codebases I've worked in, the predominant style is "int const" instead of the other way around.
  - kazinator 7y ago
    My perspective is that "const type" order consistently appears in all versions of the ISO C standard and POSIX. Every major system API I can remember working with that didn't hide const behind a typedef (like Win32's LPCSTR and whatnot) has it const first. Speaking of Microsoft, though the API's hide const with a typedef, the MSDN samples are predominantly "const char" order. I've never seen a man page with "int const". Searching all of the man pages I have installed on an Ubuntu 18 system here (literally grepping through all of /usr/share/man), I found just one with "char const" or "int const". Namely this one: $ man guestfs-hacking This contains: int commandvf (char **stdoutput, char **stderror, unsigned flags, char const *const *argv) In the same man page, there are other declarations that have the predominant convention: int commandrf (char **stdoutput, char **stderror, unsigned flags, const char *name, ...) You just worked on some unusual code bases, and are glossing over the language and system API's those code bases depended on, and their respective docs.
- guerrilla 7y ago
  Your response is an instance of the naturalistic fallacy.
  - kazinator 7y ago
    Sure, except for the part where C is a language that uses English or English-based keywords, designed by native English speakers.
    - guerrilla 7y ago
      There's no "except" because one cannot conclude how people should write programs from how they do write programs, regardless of circumstances. In any case, languages and their use change. C is 47 years old. Consistent expression structures is more important than analogies to English. Further, C is not like English and even if it were, one could not conclude that it should be or should continue to be. Moreover, that it was designed by English speakers is not evidence that it is like English or should be like English: most assembly languages were also desiged by English speakers.
      - CawCawCaw 7y ago
        So ... anything goes, then?
  - bauerd 7y ago
    It's not about moral goodness, it's about developer ergonomics. I don't see why the fallacy would apply to all value judgments
    - guerrilla 7y ago
      It's isomorphic, but you're right, I used an overly specific term. In any case, one can't conclude that something should be the way it is from the fact that it is the way it is without fruther premises, regardless of the kind of value judgements involved.
- braindeath 7y ago
  C declarators cannot in general and do not follow English grammar rules, so that is a non-sequitur.
  - kazinator 7y ago
    const int isn't a declarator; it's a list of declaration specifiers. Though these can be reordered, it's clear they were intended to follow English. In a compiler implementation, it's troublesome to enforce the order compared to processing a simple list and setting/checking flags in some data structure, diagnosing invalid duplicates or mutually exclusive situations.
    - braindeath 7y ago
      I think you're inadvertently just proving the point. I was speaking of declarators, not declaration specifiers. In C, a pointer type is part of the declarator and not the specifiers. Therefore, the CV qualifier is also part of the declarator except for the one exception of the specifier. Regardless of whether specifiers were intended to follow English (and this claim is dubious), declarators certainly were not, since it's often more natural to read them right to left, and it's generally most natural to read the left most type-specifier last. example: char *x[10]; Translated to english this is naturally stated as an array of 10 pointers to char. Not char something something array. Edit: later on I see you've moved the goal posts about the "uselessness" of cv qualifiers on pointers. I don't know what to tell you, I think that's bullshit, and there are a number of viable use-cases for them regardless of whether you have encountered them. I'm just addressing the consistency part here.
      - kazinator 7y ago
        Indeed, declarators must have their postfix chain read first, left to right, then the prefix portions right to left. (Separately at each level of parenthesization, if any, working inside out.) There is no choice about where to put const inside a declarator; the position affects the nesting level which alters the semantics. So there is no debate to be had there. Note that in declarators, the const is necessarily to the left of the thing it qualifies, so why would we put it to the right of int: int ** const ptr; ^^^ this is what is const int * const *ptr; ^^^^ this is what is const const int **ptr; ^^^ ^^^^^ these two are const In the canonical specifier order, nothing to the left of const is tainted by const: extern const int **ptr; ^^^ ^^^^^^ const and const ^^^^^^ unrelated to const For the best possible consistency, imagine const to be pissing, while the wind is blowing left to right.
- dooglius 7y ago
  I generally think of "int" as also an adjective, with both "const" and "int" describing the variable.
  - kazinator 7y ago
    That's fair, and double is obviously an adjective. struct foo maybe not so much.
  - iamnotacrook 7y ago
    "I generally think of "int" as also an adjective, with both "const" and "int" describing the variable." Eh? int is a noun, surely? How does int describe an int? I can imagine cost and long being adjectives for the noun int.
- deleted 7y ago
  [deleted]

kazinator 7y ago

It's bad cosmetic. The predominant style is "const int", following the English adjective before noun.

deleted 7y ago
[deleted]
kccqzy 7y ago
It depends on the perspective. To me and in the codebases I've worked in, the predominant style is "int const" instead of the other way around.
- kazinator 7y ago
  My perspective is that "const type" order consistently appears in all versions of the ISO C standard and POSIX. Every major system API I can remember working with that didn't hide const behind a typedef (like Win32's LPCSTR and whatnot) has it const first. Speaking of Microsoft, though the API's hide const with a typedef, the MSDN samples are predominantly "const char" order. I've never seen a man page with "int const". Searching all of the man pages I have installed on an Ubuntu 18 system here (literally grepping through all of /usr/share/man), I found just one with "char const" or "int const". Namely this one: $ man guestfs-hacking This contains: int commandvf (char **stdoutput, char **stderror, unsigned flags, char const *const *argv) In the same man page, there are other declarations that have the predominant convention: int commandrf (char **stdoutput, char **stderror, unsigned flags, const char *name, ...) You just worked on some unusual code bases, and are glossing over the language and system API's those code bases depended on, and their respective docs.
guerrilla 7y ago
Your response is an instance of the naturalistic fallacy.
- kazinator 7y ago
  Sure, except for the part where C is a language that uses English or English-based keywords, designed by native English speakers.
  - guerrilla 7y ago
    There's no "except" because one cannot conclude how people should write programs from how they do write programs, regardless of circumstances. In any case, languages and their use change. C is 47 years old. Consistent expression structures is more important than analogies to English. Further, C is not like English and even if it were, one could not conclude that it should be or should continue to be. Moreover, that it was designed by English speakers is not evidence that it is like English or should be like English: most assembly languages were also desiged by English speakers.
    - CawCawCaw 7y ago
      So ... anything goes, then?
- bauerd 7y ago
  It's not about moral goodness, it's about developer ergonomics. I don't see why the fallacy would apply to all value judgments
  - guerrilla 7y ago
    It's isomorphic, but you're right, I used an overly specific term. In any case, one can't conclude that something should be the way it is from the fact that it is the way it is without fruther premises, regardless of the kind of value judgements involved.
braindeath 7y ago
C declarators cannot in general and do not follow English grammar rules, so that is a non-sequitur.
- kazinator 7y ago
  const int isn't a declarator; it's a list of declaration specifiers. Though these can be reordered, it's clear they were intended to follow English. In a compiler implementation, it's troublesome to enforce the order compared to processing a simple list and setting/checking flags in some data structure, diagnosing invalid duplicates or mutually exclusive situations.
  - braindeath 7y ago
    I think you're inadvertently just proving the point. I was speaking of declarators, not declaration specifiers. In C, a pointer type is part of the declarator and not the specifiers. Therefore, the CV qualifier is also part of the declarator except for the one exception of the specifier. Regardless of whether specifiers were intended to follow English (and this claim is dubious), declarators certainly were not, since it's often more natural to read them right to left, and it's generally most natural to read the left most type-specifier last. example: char *x[10]; Translated to english this is naturally stated as an array of 10 pointers to char. Not char something something array. Edit: later on I see you've moved the goal posts about the "uselessness" of cv qualifiers on pointers. I don't know what to tell you, I think that's bullshit, and there are a number of viable use-cases for them regardless of whether you have encountered them. I'm just addressing the consistency part here.
    - kazinator 7y ago
      Indeed, declarators must have their postfix chain read first, left to right, then the prefix portions right to left. (Separately at each level of parenthesization, if any, working inside out.) There is no choice about where to put const inside a declarator; the position affects the nesting level which alters the semantics. So there is no debate to be had there. Note that in declarators, the const is necessarily to the left of the thing it qualifies, so why would we put it to the right of int: int ** const ptr; ^^^ this is what is const int * const *ptr; ^^^^ this is what is const const int **ptr; ^^^ ^^^^^ these two are const In the canonical specifier order, nothing to the left of const is tainted by const: extern const int **ptr; ^^^ ^^^^^^ const and const ^^^^^^ unrelated to const For the best possible consistency, imagine const to be pissing, while the wind is blowing left to right.
dooglius 7y ago
I generally think of "int" as also an adjective, with both "const" and "int" describing the variable.
- kazinator 7y ago
  That's fair, and double is obviously an adjective. struct foo maybe not so much.
- iamnotacrook 7y ago
  "I generally think of "int" as also an adjective, with both "const" and "int" describing the variable." Eh? int is a noun, surely? How does int describe an int? I can imagine cost and long being adjectives for the noun int.
deleted 7y ago
[deleted]