I like the sentiment, I love C. But this book seems riddled with errors and baffling decisions.<p>First of all, the fixed points are LITERALLY NOT FIXED POINTS. They're decimal floats. Fixed points are <i>just</i> integers that re-scale when multiplied or divided. There is no exponent field, no nothing. The author seems to have confused the notion "fixed points allow for precise calculations of monetary values" to mean that they're decimal. They're not. That section of the book contradicts itself constantly and also the code is wrong.<p>Also an ordered vector is used to implement a map/set. Because:<p>> Most people would likely instinctively reach for hash tables, and typically spend the next few months researching optimal hash algorithms and table designs.<p>> A binary searched vector is as simple as it gets and performs pretty well while being more predictable.<p>A basic hash table or hash set[1] is both simpler and faster than this solution. And I don't see what's stopping someone from spending the next few months researching optimal dynamic array growth and searching algorithms instead. This line of reasoning just doesn't make any sense.<p>And "Once nice advantage is that since they don't need any infrastructure, they're comparably cheap to create." What? It needs a dynamic array!<p>[1] <a href="https://github.com/skeeto/scratch/tree/master/set32">https://github.com/skeeto/scratch/tree/master/set32</a>
<p><pre><code> #define hc_task_yield(task)
do {
task->state = __LINE__;
return;
case __LINE__:;
} while (0)
</code></pre>
That's just diabolical. I would not have thought to write "case __LINE__". In the case of a macro, using __LINE__ twice expands to the same value where the macro is used, even if the macro has newlines. It makes sense, but TIL.
As someone who has a file with similar hacks, I will say this: I am not a C++ fan, but if you find yourself writing C code where you simulate methods via structs with function pointers often, just use C++ as a basic "C with classes" at that point. You want methods anyway, you have to go through a pointer dereference to call the function, it's just not worth the code weirdness. If you have the grit to use structs with function pointers everywhere, you have the grit to stick to the simpler subset of C++.
> C doesn't try to save you from making mistakes. It has very few opinions about your code and happily assumes that you know exactly what you're doing. Freedom with responsibility.<p>I love C because it doesn't make my life very inconvenient to protect me from stubbing my toe in it. I hate C when I stub my toe in it.
"These days; many programmers will recommend choosing a stricter language, regardless of the problem being solved. Most of those programmers wouldn't trust themselves with the kind of freedom C offers, many haven't even bothered to learn the language properly."<p>Same thing people said about other people not compiling by hand lol.
> The reason I believe C is and always will be important is that it stands in a class of its own as a mostly portable assembler language, offering similar levels of freedom.<p>When your computer is a PDP-11, otherwise it is a high level systems language like any other.
> Using a stricter language helps with reducing some classes of bugs, at the cost of reduced flexibility in expressing a solution and increased effort creating the software.<p>First of all, those languages do not "help" "reducing" some classes of bugs. They often entirely remove them.<p>Then, even assuming that any safe language with unsafe regions (Rust, C#, etc) would not give you comparable flexibility at a fraction of the risk... if your flexible, effortless solution contains entire classes of bugs, then there is no point in comparing "effort". You should at least take into account the effort in providing a software with a high confidence that those bugs are not there.
Beware that the second section about fixed-point arithmetic is actually about floating point with exponent in base 10.<p>Besides, the operations are all wrong and only work for trivial values of the exponents, like 0, 1 and 2.
> Microsoft has unfortunately chosen to neglect C for a long time, its compilers dragging far behind the rest of the pack.<p>Is this still true? MSVC is pretty good at compiling C++ nowadays
Some points about the introduction, but otherwise this seems like an interesting collection of (slightly deranged?) patterns in C.<p><i>> The truth is that any reasonably complicated software system created by humans will have bugs, regardless of what technology was used to create it.</i><p>"Drivers wearing seatbelts still die in car accidents and in some cases seatbelts prevent drivers from getting out of the wreckage so we're better off without them." This is cope.<p><i>> Using a stricter language helps with reducing some classes of bugs, at the cost of reduced flexibility in expressing a solution and increased effort creating the software.</i><p>...and a much smaller effort debugging the software. A logic error is much easier to reason about than memory corruption or race condition on shared memory. The time you spend designing your system and handling the errors upfront pays dividends later when you get the inevitable errors.<p>I'm not saying that all software should be rewritten in memory-safe languages, but I'd rather those who choose to use the only language where this kind of errors regularly happens be honest about it.