11 ms·

Looks reasonable to me. I've been programming C daily for 25 years. Cosmetic but it is nice to see "int const foo;" being preferred to "const int foo". And "We

Looks reasonable to me. I've been programming C daily for 25 years. Cosmetic but it is nice to see "int const foo;" being preferred to "const int foo". And "We define variables as close to their first use as possible". Less cosmetically, section 5.6 on named constants is great. That's a fiddly area of C from which to pull out reliable advice.

kazinator 7y ago
There is no technical reason to prefer one or the other; they are both declaration specifiers which can occur in any order. long const int is valid, even. The const qualification is in the type; it is not a direct attribute of foo, so putting the const closer to foo means nothing.
- eMSF 7y ago
  The point isn't about putting it closer to the variable name, but consistently to the right of what it applies to. But yes, it is a matter of opinion.
  - mumblemumble 7y ago
    I'm only an infrequent C programmer, but that goal interests me simply because it seems unattainable given other aspects of C's syntax. If qualifiers went to the right of things they qualify, I'd expect variable declarations to look more like: foo: int const; And similarly, function declarations might also take a more ML-like syntax. C seems more like it wants to be an adjectives-before-nouns type of language.
    - guerrilla 7y ago
      See wahern and my response to the grandparent.
      - mumblemumble 7y ago
        So, IOW, it's not purely a point of style, it's more about what's a sane way to write things given the requirements of the language's syntax when you're dealing with pointer declarations? Which would explain why it seems so odd to me; I spent a fair amount of time in C-style languages, but typically only ones that lack pointers.
        guerrilla 7y ago
        I think it can be both, plus communication: communication to n00bs, to yourself in the future if you're really tired, etc.
        mumblemumble 7y ago
        Though, if the goal is communication, wouldn't it be clearer still to use typedefs to clean up more complex declarations a bit? Or does that end up making things worse?
        guerrilla 7y ago
        People do that if such a type is used a lot but probably not if it's just a one-off, just like when they write a function instead of using the same snippet a lot but don't if it isn't.
  - kazinator 7y ago
    To the right of what it applies to? Like French: Moulin Rouge. :)
    - forty 7y ago
      In French it can be either left or right depending on the word: un moulin rouge (a red mill) but un vieux moulin (an old mill)
- wahern 7y ago
  It's a good habit to get into, though, when it comes to pointer types. How many times have people written code like: const int *foo; when they meant int *const foo; or const int *const foo;
  - loeg 7y ago
    Rarely does someone mean: int *const foo; It's mostly useless to declare a variable that cannot be assigned. But very often people write const int **foo; When they intended const int * const *foo;
    - tempodox 7y ago
      > It's mostly useless to declare a variable that cannot be assigned. So all functional languages (where immutability is the default) are mostly useless?
      - loeg 7y ago
        If you declare a variable in this way in C, it can never be assigned. Not once — zero times. What is or is not good practice in C has little bearing on or relationship to functional languages, so I'm not sure why you bring them up in this context.
    - JoachimSchipper 7y ago
      FWIW, I find that form quite useful for defining short aliases, e.g. int *const current_foo = &items[i].bar.foo; before some complicated manipulations on current_foo. (A decent (SSA-)optimizing compiler will produce identical code with and without the declaration.)
      - loeg 7y ago
        Yeah, this only works if you initialize at the same time as declaration. And as you say, without const, the same code is generated. All it prevents is accidental reuse of current_foo, which may have some value.
- guerrilla 7y ago
  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.
- xpqsa 7y ago
  The down-votes on "Hacker" "News" are amusing again. Never argue in a technically correct manner here. Use misdirection, grandeur and talk in a presidential voice. This is not comp.lang.c. How is the DS 9000 for C11 coming along? ;)
red75prime 7y ago
Still only signed int for typed constants. Are there some plans to mitigate it? It's a pain point for FFI.

kazinator 7y ago

There is no technical reason to prefer one or the other; they are both declaration specifiers which can occur in any order. long const int is valid, even. The const qualification is in the type; it is not a direct attribute of foo, so putting the const closer to foo means nothing.

eMSF 7y ago
The point isn't about putting it closer to the variable name, but consistently to the right of what it applies to. But yes, it is a matter of opinion.
- mumblemumble 7y ago
  I'm only an infrequent C programmer, but that goal interests me simply because it seems unattainable given other aspects of C's syntax. If qualifiers went to the right of things they qualify, I'd expect variable declarations to look more like: foo: int const; And similarly, function declarations might also take a more ML-like syntax. C seems more like it wants to be an adjectives-before-nouns type of language.
  - guerrilla 7y ago
    See wahern and my response to the grandparent.
    - mumblemumble 7y ago
      So, IOW, it's not purely a point of style, it's more about what's a sane way to write things given the requirements of the language's syntax when you're dealing with pointer declarations? Which would explain why it seems so odd to me; I spent a fair amount of time in C-style languages, but typically only ones that lack pointers.
      - guerrilla 7y ago
        I think it can be both, plus communication: communication to n00bs, to yourself in the future if you're really tired, etc.
        mumblemumble 7y ago
        Though, if the goal is communication, wouldn't it be clearer still to use typedefs to clean up more complex declarations a bit? Or does that end up making things worse?
        guerrilla 7y ago
        People do that if such a type is used a lot but probably not if it's just a one-off, just like when they write a function instead of using the same snippet a lot but don't if it isn't.
- kazinator 7y ago
  To the right of what it applies to? Like French: Moulin Rouge. :)
  - forty 7y ago
    In French it can be either left or right depending on the word: un moulin rouge (a red mill) but un vieux moulin (an old mill)
wahern 7y ago
It's a good habit to get into, though, when it comes to pointer types. How many times have people written code like: const int *foo; when they meant int *const foo; or const int *const foo;
- loeg 7y ago
  Rarely does someone mean: int *const foo; It's mostly useless to declare a variable that cannot be assigned. But very often people write const int **foo; When they intended const int * const *foo;
  - tempodox 7y ago
    > It's mostly useless to declare a variable that cannot be assigned. So all functional languages (where immutability is the default) are mostly useless?
    - loeg 7y ago
      If you declare a variable in this way in C, it can never be assigned. Not once — zero times. What is or is not good practice in C has little bearing on or relationship to functional languages, so I'm not sure why you bring them up in this context.
  - JoachimSchipper 7y ago
    FWIW, I find that form quite useful for defining short aliases, e.g. int *const current_foo = &items[i].bar.foo; before some complicated manipulations on current_foo. (A decent (SSA-)optimizing compiler will produce identical code with and without the declaration.)
    - loeg 7y ago
      Yeah, this only works if you initialize at the same time as declaration. And as you say, without const, the same code is generated. All it prevents is accidental reuse of current_foo, which may have some value.
guerrilla 7y ago
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.
xpqsa 7y ago
The down-votes on "Hacker" "News" are amusing again. Never argue in a technically correct manner here. Use misdirection, grandeur and talk in a presidential voice. This is not comp.lang.c. How is the DS 9000 for C11 coming along? ;)

red75prime 7y ago

Still only signed int for typed constants. Are there some plans to mitigate it? It's a pain point for FFI.