4 ms·

For personal projects, I'm going to try and use ANSI C89 forever. I know this isnt especially rational but it's somehow appealing to stick with a small(er) and

by frou_dh 15y ago

For personal projects, I'm going to try and use ANSI C89 forever. I know this isnt especially rational but it's somehow appealing to stick with a small(er) and more historic version.

haberman 15y ago
I think that <stdint.h> is a C99 feature worth using -- otherwise each project has to redefine eg. myuint32_t over and over again. Colossal waste of effort and namespace pollution.
- TheNewAndy 15y ago
  Most of the time you don't actually care about the exact size of your integer types (especially for signed integers). At work, we use C90 with a few C99 extensions which can be disabled through the preprocessor (e.g. inline, restrict) and although we stared out with a stdint.h like thing, it is proving to be less useful.
- frou_dh 15y ago
  Definitely. That's comfort for the existence of "long long"!
endgame 15y ago
That's your call and I admire it (I think that restriction is a major cause of Lua's famous portability). I like the C99 struct initialisers and the ability to declare things right next to their use site too much to go back.
ysangkok 15y ago
Good luck in convincing anyone that doing something that's not rational is a good idea. The very definition of rationality is something that represents something good and necessary. I don't know why you'd try and argue for non-rationality/mysterious/spiritual reasons when using something is mathematical and scientific as computers. It's a bad combination. Also, you don't have to use the whole standard. You know there are people who use C++ for hobby projects? That standard is dozens of times larger than the C standard.
- frou_dh 15y ago
  I doubt any programmer practices platform, tool and library choice with 100% rationality, so it's not a black and white issue. If I had in fact been trying to convince people and hadn't brought up irrationality myself, your concern would be welcome :)
- jballanc 15y ago
  I don't know why you would consider the choice of C89 irrational. If you want the widest range of compiler portability, you pretty much have to use C89.
radarsat1 15y ago
I'd really _like_ to use C99, but unfortunately Microsoft is putting a damper on my fun. It drives me crazy: for once I was working on a project from scratch and decided to go ahead and enjoy myself using all the niceties of C99 that are available in GCC, and then people come along and complain that they can't compile it in Visual Studio. Even though I don't use Windows, if I want a certain cross-section of the developer community to be interested in my work, MS is effectively able to tell me what to do. I'm forced to use the lowest common denominator, which they have decided is not going to be C99, so I end up having to start back-porting my work to C89 or tell these people they need to use MingW. (Which apparently is not an acceptable solution even though it technically works.. it's just complicated enough to set up an MSys bash prompt that it turns people off.)
zvrba 15y ago
I gave up from C99 and its successors when I saw that they introduced _Bool. Actually, I've never understood the meaning behind having a boolean type in any language. [It would kinda make sense if conditionals accepted ONLY boolean arguments, and then having bool type would make sense only as a return value of a function. Why somebody feels a need to declare a boolean variable is beyond me.]
- dextorious 15y ago
  So your intentions with the bool using code/signatures are clearer. Isn't it OBVIOUS?
  - zvrba 15y ago
    No, it's not. Adding a new built-in type that doesn't participate in type-checking in any meaningful way just clutters the language. _Bool is like int, just having unspecified size and slower, since the compiler has to ensure that it shall contain etiher 0 or 1. Very little, if anything, would have been lost by standardizing "typedef unsigned bool;"
    - dextorious 15y ago
      """No, it's not. Adding a new built-in type that doesn't participate in type-checking in any meaningful way just clutters the language.""" 1) It's not about type-checking, it's about reading code. 2) It's not like type-checking is C's strong point.
- kzrdude 15y ago
  There are so many different ways to communicate errors through an int in C. For example 0=success and negative error codes. With _Bool, at least one scheme is obvious from the signature.

by frou_dh 15y ago

For personal projects, I'm going to try and use ANSI C89 forever. I know this isnt especially rational but it's somehow appealing to stick with a small(er) and more historic version.

haberman 15y ago

I think that <stdint.h> is a C99 feature worth using -- otherwise each project has to redefine eg. myuint32_t over and over again. Colossal waste of effort and namespace pollution.

TheNewAndy 15y ago
Most of the time you don't actually care about the exact size of your integer types (especially for signed integers). At work, we use C90 with a few C99 extensions which can be disabled through the preprocessor (e.g. inline, restrict) and although we stared out with a stdint.h like thing, it is proving to be less useful.
frou_dh 15y ago
Definitely. That's comfort for the existence of "long long"!

endgame 15y ago

That's your call and I admire it (I think that restriction is a major cause of Lua's famous portability). I like the C99 struct initialisers and the ability to declare things right next to their use site too much to go back.

ysangkok 15y ago

Good luck in convincing anyone that doing something that's not rational is a good idea. The very definition of rationality is something that represents something good and necessary. I don't know why you'd try and argue for non-rationality/mysterious/spiritual reasons when using something is mathematical and scientific as computers. It's a bad combination. Also, you don't have to use the whole standard. You know there are people who use C++ for hobby projects? That standard is dozens of times larger than the C standard.

frou_dh 15y ago
I doubt any programmer practices platform, tool and library choice with 100% rationality, so it's not a black and white issue. If I had in fact been trying to convince people and hadn't brought up irrationality myself, your concern would be welcome :)
jballanc 15y ago
I don't know why you would consider the choice of C89 irrational. If you want the widest range of compiler portability, you pretty much have to use C89.

radarsat1 15y ago

I'd really _like_ to use C99, but unfortunately Microsoft is putting a damper on my fun. It drives me crazy: for once I was working on a project from scratch and decided to go ahead and enjoy myself using all the niceties of C99 that are available in GCC, and then people come along and complain that they can't compile it in Visual Studio. Even though I don't use Windows, if I want a certain cross-section of the developer community to be interested in my work, MS is effectively able to tell me what to do. I'm forced to use the lowest common denominator, which they have decided is not going to be C99, so I end up having to start back-porting my work to C89 or tell these people they need to use MingW. (Which apparently is not an acceptable solution even though it technically works.. it's just complicated enough to set up an MSys bash prompt that it turns people off.)

zvrba 15y ago

I gave up from C99 and its successors when I saw that they introduced _Bool. Actually, I've never understood the meaning behind having a boolean type in any language. [It would kinda make sense if conditionals accepted ONLY boolean arguments, and then having bool type would make sense only as a return value of a function. Why somebody feels a need to declare a boolean variable is beyond me.]

dextorious 15y ago
So your intentions with the bool using code/signatures are clearer. Isn't it OBVIOUS?
- zvrba 15y ago
  No, it's not. Adding a new built-in type that doesn't participate in type-checking in any meaningful way just clutters the language. _Bool is like int, just having unspecified size and slower, since the compiler has to ensure that it shall contain etiher 0 or 1. Very little, if anything, would have been lost by standardizing "typedef unsigned bool;"
  - dextorious 15y ago
    """No, it's not. Adding a new built-in type that doesn't participate in type-checking in any meaningful way just clutters the language.""" 1) It's not about type-checking, it's about reading code. 2) It's not like type-checking is C's strong point.
kzrdude 15y ago
There are so many different ways to communicate errors through an int in C. For example 0=success and negative error codes. With _Bool, at least one scheme is obvious from the signature.