I personally prefer Prehistoric C, which only has the two language keywords "ugh" and "grunt". Modern C has too many keywords for my taste.
"Prehistoric" or not, the classical C as created by Kernighan and Ritchie is actually a perfect example of a sensibly minimalist design. Subsequent changes made to the language have spoiled the characteristic elegance of that design.
Modern C [pdf]
281–290 of 396 posts
Re: Modern C [pdf]
#282Earlier quoted context omitted.
> HN is probably something like 99% web and app developers Most generalizations about HN are merely projection based on sample bias, so please don't post such generalizations unless you have representative data. We're thinking about adding that sentence to the site guidelines, because spurious general claims about HN are a cliché here.
Except that this is a discussion on how news and topics are received at HN. So making a projection based on available data is actually quite reasonable and if there is a sample bias, it is a valid one. Because it doesn't matter if there are nine hundred billion hardcore VHDL folk around here. The most popular discussions tend to be tech related to web technologies and the associated tools. If the consistently popular…
It's extremely common to do this (I'm not picking on you personally!), but such generalizations have no objective value and lead to repetitive, low-quality discussion, which is why I think we're going to add a guideline asking people not to do it.
Re: Modern C [pdf]
#283While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…
> I would not let that line pass code review. At least it's not for (size_t i = 9; i >= 0; --i) :-)
edit: Ok, looking at it again the parent example is probably going to overflow or something right?
Re: Modern C [pdf]
#284Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.
I've found goto to be a good way of dealing with exceptions in low-level C. For example: void* foo() { int handle = get_some_handle(); if (handle I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.
Re: Modern C [pdf]
#285Earlier quoted context omitted.
This is a hilariously bad attitude for any software that other people will use. When software crashes, people lose work and time. When software has vulnerabilities, bad guys take advantage of them and build stronger botnets. "The danger" isn't like wiping out when you're pulling a stunt; "the danger" is wasting the good guys' time and empowering bad guys. Computers aren't just tools, they're also toys. People use com…
What's amusing to me is the amount of terribly unsafe code (that isn't C) that powers rockets, moon landers, and a variety of other safety-critical systems and yet isn't the subject of such persistent and severe criticisms. There's a reason C and C++ are targets. My (obviously controversial) opinion is it has at least as much to do with ego as a desire for safety.
Re: Modern C [pdf]
#286I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…
I don't hate C. I'd rather program in C than C++. There's a "uniformity" and simplicity about C that makes it beautiful. You've got structs, functions, and pointers...that's it. I remember reading some of ID's engine code and admiring how well I could follow it and know what's going on. With C++ and other OO languages, it's much harder. Don't get me wrong, I'm not going to write my next web app in C, and there's some…
Npte though that id hasn't really created an influential game in 15 years and arguably the game of the century (Minecraft) was programmed, badly from what I hear, in Java. People often say that "you can write good C code" without considering what you're giving up in terms of architecture and creativity.
Re: Modern C [pdf]
#287Earlier quoted context omitted.
> I would not let that line pass code review. At least it's not for (size_t i = 9; i >= 0; --i) :-)
Your for loop works, whereas the one in the parent comment would run forever, correct? Is there something I'm missing here? edit: Ok, looking at it again the parent example is probably going to overflow or something right?
The other way around: size_t is an unsigned type, so decrementing 0 will wrap around to SIZE_MAX, a value that is positive as well as greater than 9. This means counter to your intuition, the first loop will terminate and the second one won't.
Re: Modern C [pdf]
#288Earlier quoted context omitted.
It was the first object-oriented language that I learned, and some of my classmates' first language. It wasn't too bad to be told "Just type it for now; we'll get into object orientation next week and explain it then." From my own experience, I don't think it's a big issue if it's introduced correctly.
I suspect you are far more willing to learn by rote than some other students. For a particular kind of curious student, "just do it because you have to" is a very fast way to them checking out and doing nothing at all.
Re: Modern C [pdf]
#289Earlier quoted context omitted.
You are right, "do not happen" sounds too much like "will never happen". See also Wikipedia's entry about that example[0]. My point is that if the programmer can't prove accesses are always within appropriate bounds, there should be a runtime check. That is simple. This is not "slow" (and even in the case it you need it fast and are ok to randomly crash, avoiding checks should be explicit). And some languages do it b…
Well, yes, I agree in general bounds should be checked at runtime when it isn't possible to statically verify access at compile time. I'm not sure how default access in C or C++ isn't explicitly avoiding checks. By definition "a[b]" is an unchecked dereference. It doesn't get more explicit than "by definition." Of course if by "explicit" you mean "syntax exists that demarcates unchecked access" then C and C++ will ne…
Re: Modern C [pdf]
#290If people aren't so into this book, can anyone suggest some other book beyond K&R?
If you like it, great, if you don't, you have company[2]
[0] https://learncodethehardway.org/c/
[1] https://web.archive.org/web/20141205223016/http://c.learncod...