Yeah that dumbass Zed Shaw, looking at not even half done freetard stuff is a waste of time. There is K&R and a lot of good contributions to stackoverflow [1].
[1] http://stackoverflow.com/questions/4810664/how-do-i-use-arra...
[1] http://stackoverflow.com/questions/4810664/how-do-i-use-arra...
Also, it's a pretty fun way to practice my creative writing. :-)
K&R is an excellent reference, and LCTHW covers some new topics like valgrind, which is great.
However, it fails to point out that some of the exercises are just that; exercises. For example, creating a custom type system in C. Never do this.
Some other failings include; little attention to testing, no mention of cmake (used in major projects like opencv and clang) or lint(!), criticism of K&R systax (arguably validly so, but industry standard is industry standard).
Look there's a lot of good in Learn C the Hard Way. I completely recommend it as a way to learn some C... but don't make the mistake of assuming a new book is better than an old book just because it's new.
If you're programming C, read K&R. If you're doing it professionally, you probably also want to read Deep Sea Programming by Peter van der Linden.
> K&R is an excellent reference, and LCTHW covers some new topics like valgrind, which is great.
Wrong, I already demonstrate that they have an example that is basically strcpy() and I show why it's broken. By the time I'm done with the book I'll have taken apart the entire book and shown that it's the source of most security holes through poor examples.
> However, it fails to point out that some of the exercises are just that; exercises. For example, creating a custom type system in C. Never do this.
Totally wrong. You basically just said that all of gobjects (the foundation of Gnome) should not exist, yet it's a successful object oriented abstraction. You may think that's true, but then you'd be in the vast minority. Without a demonstrated reason why one should never do this, your statement is total bullshit.
> Some other failings include; little attention to testing, no mention of cmake (used in major projects like opencv and clang) or lint(!), criticism of K&R systax (arguably validly so, but industry standard is industry standard).
There's extensive attention to testing, with nearly every exercise having use of valgrind and the inclusion of defensive programming macros not found in most other books PLUS a constant demand to break the code they've just written. In the second half of the book I'll be including the testing suite I use in my own projects:
https://github.com/zedshaw/mongrel2/blob/master/tests/minuni...
This claim is borderline slanderous it's so wrong.
Edit: And cmake is a piece of crap that isn't better than modern make.
> Look there's a lot of good in Learn C the Hard Way. I completely recommend it as a way to learn some C... but don't make the mistake of assuming a new book is better than an old book just because it's new.
Meanwhile, you make the mistake of not questioning the code in K&R when a cursory read finds numerous flaws and buffer overflows. If you feel that people should evaluate all things objectively (I agree!) then do it yourself and actually read K&R again.
And by the way, they updated it several times to remove defects since you probably read it. My copy was only a few years old and I had to update it because they fixed bugs in that copy() function I tear apart (but not enough).
> If you're programming C, read K&R. If you're doing it professionally, you probably also want to read Deep Sea Programming by Peter van der Linden.
I agree, solid recommendations, but I'm going to advocate people read K&R for historical reasons and to practice code review, which is what I'm doing in my book.
strcpy() is not broken. You cannot expect a function to work if you violate its preconditions. Exercise for you: enumerate strcpy's preconditions. And once you know them, you design your program in accord with them.
> There's extensive attention to testing
Testing can only prove the presence of bugs, not their absence. Heavy emphasis on testing leads to coding by trial-and-error, which, I argue, is the prime source of bugs (security and others).
"Hey, I tested it, it works!" What's missing in that statement is that it works for usual test cases. Software breaks on unusual/abnormal inputs. If, e.g., strcpy causes buffer overflow in your program, it is YOUR code that is crap because it didn't ensure proper preconditions. Don't project your incompetence/stupidity on strcpy.
THIS is what programmers should learn.
Your quote from K&R "critique": "And, what's the point of a book full of code you can't actually use in your own programs?" This line of thinking is despicable. A book is supposed to teach people ideas and concepts, not give them ready-made code recipes that they can copy-paste in their own programs.
However, I will repeat.
K&R is an excellent text. If you disagree, I dispute your credibility.
I also stand by my comment. Smart people have created strong type systems like gobjects and ctypes in C.
As a programmer, you should unequivocally _never_ do this yourself. C is about reuse, and not reinventing the wheel. Sure, if you want to use a strong type system instead of C++, do so. Do not write one yourself.
Bullshit. You guys going around throwing your platitudes, shoulds, and nevers at people rarely have any evidence supporting your claims, and usually it just hides a lack of real knowledge.