| General > General Technical Chat |
| How many people code in C these days, and if so, why? |
| << < (50/99) > >> |
| chriva:
Finding new ways to abstract things that in effect are the same thing is making the code harder to read if anything. |
| madires:
--- Quote from: SiliconWizard on May 10, 2020, 02:18:27 pm ---And yes C99 added a true boolean type (_Bool, or bool if you include stdbool.h) which is guaranteed to hold only 1 or 0 (unless probably you mess with it using pointers and casts). I've never been really bothered with older C versions not having a true boolean type. All you had to know was that 0 was considered false as a condition, and anything else, true. That worked well enough. There was no point directly testing a "boolean" (I'd say rather a "condition") against a value anyway (something I have already seen from some developers - ugly!) This would make no sense. One way it could make sense would be if you used a bool value not as a condition but as an integer value in some calculation. Something I've seen, but I find this wrong in many ways, and obfuscating. It doesn't even make sense from a strict type point of view IMO. --- End quote --- The C way of using an unsigned integer as boolean variable is very similar to the assembler CPU commands. From a software developer's point of view of a clean and perfect language it seems bad and ugly, but when you consider assembler it's actually beautiful. You can use it as a boolean flag and a counter as the same time. More efficient than using two variables, one boolean flag and a counter. |
| SiliconWizard:
--- Quote from: madires on May 10, 2020, 03:07:12 pm --- --- Quote from: SiliconWizard on May 10, 2020, 02:18:27 pm ---And yes C99 added a true boolean type (_Bool, or bool if you include stdbool.h) which is guaranteed to hold only 1 or 0 (unless probably you mess with it using pointers and casts). I've never been really bothered with older C versions not having a true boolean type. All you had to know was that 0 was considered false as a condition, and anything else, true. That worked well enough. There was no point directly testing a "boolean" (I'd say rather a "condition") against a value anyway (something I have already seen from some developers - ugly!) This would make no sense. One way it could make sense would be if you used a bool value not as a condition but as an integer value in some calculation. Something I've seen, but I find this wrong in many ways, and obfuscating. It doesn't even make sense from a strict type point of view IMO. --- End quote --- The C way of using an unsigned integer as boolean variable is very similar to the assembler CPU commands. From a software developer's point of view of a clean and perfect language it seems bad and ugly, but when you consider assembler it's actually beautiful. You can use it as a boolean flag and a counter as the same time. More efficient than using two variables, one boolean flag and a counter. --- End quote --- Just a detail - it doesn't need to be unsigned. It's again just 0 or not 0. And sure the idea was to make efficient use of underlying CPUs. But it's not particularly ugly. Some people may find it quirky, but that's largely questionable. In my eyes, "0" or "not 0" are 2 distinct states that are perfectly valid for holding a boolean value. People insisting on it needing to strictly have only two different values (like 0 or 1) are just biased seeing a boolean as a binary digit. 0 or 1 have no particular meaning per se. All a boolean needs to hold IMHO are two different and exclusive states. The rest is mind wanking IMO. YMMV. |
| nctnico:
Agreed. For all we know 'true' may be defined as 42 >:D |
| IDEngineer:
With respect to the use of booleans in C.... I'm a huge proponent of the style "if (boolean)" or "if (!boolean)" for several reasons. First, IMHO it's concise and clearly conveys what is being evaluated. YMMV. Second, long ago I was analyzing the Assembly language output from a compiler and found that it generated different code depending upon how if statements were written. If I wrote "if (variable)" or "if (!variable)", it generated ultra-tight code by clearing the Z flag, pulling the variable into a register, OR'ing the register with itself which (might) set the Z flag, and then testing the state of the Z flag. But if I wrote "if (variable == true)" the compiler actually performed a comparison with an immediate value equal to "true" (or whatever value was specified), generating signficantly more Assembly instructions for the same net result. Having learned this, I also started testing non-boolean variables for zero with "if (!variable)" which yielded smaller, faster code as described above. This was especially nice (and low cost) when checking for null pointers. I lived in this blissful state for a very long time. THEN... my code started failing in weird ways on some project. So I dug into the Assembly generated by THAT compiler, and to my horror discovered that it did not generate proper Assembly unless a value was specified for the comparison! That is, "if (boolean)" and "if (!boolean)" generated BROKEN CODE but "if (boolean == true)" and "if (boolean == false)" did not. The != versions also generated proper code. The compiler simply demanded two explicit values to compare. I could not believe it, but I was trapped by the authors of that compiler. Once I rewrote my code to always provide a value against which to compare, it started working perfectly. This is a long winded way of saying that despite agreeing it looks terrible and should not be necessary, I now write "if (boolean == true)" even though strictly speaking it is not necessary. I do so because that source code will always work with every compiler I've ever encountered, whereas I know there's a team out there somewhere that wrote a compiler where that would silently (e.g. without reporting an error, nor even a warning) generate broken code without the immediate value. Supporting two values with a comparison operator between them is so fundamental to the language that we can safely presume it will always work, so for reliability I now write that way. And I urge the universe to inflict terrible harm on that compiler team every time I do so. |
| Navigation |
| Message Index |
| Next page |
| Previous page |