3 ms·

The author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one

The author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one that was adopted way back when.

lelanthran 3y ago
> The author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one that was adopted way back when. They didn't adopt it for the same reason that it is a bad idea now - too many programs already contained at least one variable named after his types. If the standard had adopted his convention, too many programs will break, which is why his convention is currently unsuitable for any existing project.
- otikik 3y ago
  Wouldn’t existing programs just continue working? What the author did was adding new types, not modifying or removing existing ones.
  - iforgotpassword 3y ago
    Because those existing programs surely don't use the same identifiers for other stuff? Certainly there is no code out there using s8 for "signed char" instead of "utf8 string"? :-)
  - lelanthran 3y ago
    > Wouldn’t existing programs just continue working? Only ones which don't have variables named `i8` or `b32` (which is common, but not for booleans). I've seen many projects which used the pattern [a-z][1-9]+ as variables. Those programs with a variable called `i8` won't compile if the standard made a type called `i8`. In particular, the standard reserves entire patterns to itself, so it cannot reserve the pattern of [a-z][0-9]+. They could, and did, reserve the pattern *int*_t for themselves.
    - otikik 3y ago
      But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work. In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations.
      - lelanthran 3y ago
        > But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work. For libraries, yes, but we're talking about why the standard didn't do it. The standard did not want[1] to reserve keywords that current programs were already using. A library that conflicts on keywords will only break with those programs that use it. A standard that conflicts on keywords breaks all programs in that language. > In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations. One of the constraints of taking decisions is to work within the limits existing framework - if you're avoiding the alternatives that don't break, then it's the decision-makers bug, not the frameworks. The framework has limitations, widely published and known. You make decisions within those limitations. [1] Although, they do do it, it's only with relectance, not on a whim to avoid typing a few characters)
    - gdprrrr 3y ago
      Typedefs and variable namens don't live in them same namespace, do they?
      - lelanthran 3y ago
        > Typedefs and variable namens don't live in them same namespace, do they? Depends. See this snippet: https://www.godbolt.org/z/5T5jz47q4 https://www.godbolt.org/z/5T5jz47q4 Cannot declare a variable called `u8` when there is a typedef of `u8`. And even when you can declare a variable called (for example) `int`, that effectively "breaks" the program by not being even a tiny bit readable anymore.
    - 3y ago
iforgotpassword 3y ago
That ship has sailed ages ago. There are some things you should just accept about C, or any programming language really. Just because you can do something doesn't mean you should do something. I don't know how many years of experience in C this guy has, but this is a "been there, done that" case for me. I stick to stdint and stdbool today, and even if only half the code/libs I interface with do that, it's already worth the extra _t-typing all the time. Just the fact that they use the i prefix for signed, and s for string has a high chance that his s8 string type gets confused with an 8-bit signed int. But as you say, it's a personal style, and the author seems to be aware of that: > I’m not saying everyone should write C this way, and when I contribute code to a project I follow their local style. Because that's by far the most important rule to follow in any language. I think the rest is less controversial, the 0 vs. NULL thing has been going on forever; I didn't check recently but I'd assume "const somestruct *foo" would still sometimes help out the compiler to optimize vs. the non-const version.
- stephc_int13 3y ago
  I use very similar types as the author in my own libs and framework. I think this is perfectly legitimate, in the same way that I don't use std libs directly but always behind wrappers or my own implementation. The C std lib and default types are often what is keeping the language back. And they should be used when you have no other choice. Short name for scalar types is also pretty much the new standard for modern languages such as Zig.
marwis 3y ago
In case of winapi you can actually generate your own headers following the style you want, see for example https://github.com/microsoft/cppwin32 https://github.com/microsoft/cppwin32

The author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one that was adopted way back when.

lelanthran 3y ago

> The author did qualify it with personal coding style. Frankly the standard types are too verbose and I wish this guy's elegant and clear list had been the one that was adopted way back when. They didn't adopt it for the same reason that it is a bad idea now - too many programs already contained at least one variable named after his types. If the standard had adopted his convention, too many programs will break, which is why his convention is currently unsuitable for any existing project.

otikik 3y ago
Wouldn’t existing programs just continue working? What the author did was adding new types, not modifying or removing existing ones.
- iforgotpassword 3y ago
  Because those existing programs surely don't use the same identifiers for other stuff? Certainly there is no code out there using s8 for "signed char" instead of "utf8 string"? :-)
- lelanthran 3y ago
  > Wouldn’t existing programs just continue working? Only ones which don't have variables named `i8` or `b32` (which is common, but not for booleans). I've seen many projects which used the pattern [a-z][1-9]+ as variables. Those programs with a variable called `i8` won't compile if the standard made a type called `i8`. In particular, the standard reserves entire patterns to itself, so it cannot reserve the pattern of [a-z][0-9]+. They could, and did, reserve the pattern *int*_t for themselves.
  - otikik 3y ago
    But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work. In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations.
    - lelanthran 3y ago
      > But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work. For libraries, yes, but we're talking about why the standard didn't do it. The standard did not want[1] to reserve keywords that current programs were already using. A library that conflicts on keywords will only break with those programs that use it. A standard that conflicts on keywords breaks all programs in that language. > In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations. One of the constraints of taking decisions is to work within the limits existing framework - if you're avoiding the alternatives that don't break, then it's the decision-makers bug, not the frameworks. The framework has limitations, widely published and known. You make decisions within those limitations. [1] Although, they do do it, it's only with relectance, not on a whim to avoid typing a few characters)
  - gdprrrr 3y ago
    Typedefs and variable namens don't live in them same namespace, do they?
    - lelanthran 3y ago
      > Typedefs and variable namens don't live in them same namespace, do they? Depends. See this snippet: https://www.godbolt.org/z/5T5jz47q4 https://www.godbolt.org/z/5T5jz47q4 Cannot declare a variable called `u8` when there is a typedef of `u8`. And even when you can declare a variable called (for example) `int`, that effectively "breaks" the program by not being even a tiny bit readable anymore.
  - 3y ago

iforgotpassword 3y ago

That ship has sailed ages ago. There are some things you should just accept about C, or any programming language really. Just because you can do something doesn't mean you should do something. I don't know how many years of experience in C this guy has, but this is a "been there, done that" case for me. I stick to stdint and stdbool today, and even if only half the code/libs I interface with do that, it's already worth the extra _t-typing all the time. Just the fact that they use the i prefix for signed, and s for string has a high chance that his s8 string type gets confused with an 8-bit signed int. But as you say, it's a personal style, and the author seems to be aware of that: > I’m not saying everyone should write C this way, and when I contribute code to a project I follow their local style. Because that's by far the most important rule to follow in any language. I think the rest is less controversial, the 0 vs. NULL thing has been going on forever; I didn't check recently but I'd assume "const somestruct *foo" would still sometimes help out the compiler to optimize vs. the non-const version.

stephc_int13 3y ago
I use very similar types as the author in my own libs and framework. I think this is perfectly legitimate, in the same way that I don't use std libs directly but always behind wrappers or my own implementation. The C std lib and default types are often what is keeping the language back. And they should be used when you have no other choice. Short name for scalar types is also pretty much the new standard for modern languages such as Zig.

marwis 3y ago

In case of winapi you can actually generate your own headers following the style you want, see for example https://github.com/microsoft/cppwin32 https://github.com/microsoft/cppwin32