61–70 of 127 posts
I just wish to learn the current state of the art - what are best practices that have evolved since K&R?
Reading through Zed's tutorial reminded me of some Pascal and C tutorials I downloaded in the old BBS days. They were a great introduction to both languages when I was just learning to program. I just had a look on simtel but I couldn't find them. Maybe you should put some effort into scanning old software archives and seeing if you can unearth them. C is pretty old - you wouldn't be the first one that had this idea.
Earlier quoted context omitted.
I don't think the learner would appreciate the subtleties, and I don't agree that they'll learn anything from it. I can reinforce each lesson/problem you're describing one by one through the exercises, but a new person simply wouldn't know good code if it slapped them in the face. Confer with Learn Python the Hard Way to get a feel for the aesthetic and technique I'm working towards. I don't want to write bulletproof…
> I don't want to write bulletproof code, I want to teach them how and why to write bulletproof code. This confuses me. How can you teach someone to do something if you won't do it yourself? Reading your statement literally, you are effectively going to say, "This is how and why to write bulletproof code, but I'm not going to." The whole point of LxTHW is to learn by doing. If you're doing it wrong, they're learning…
I understood K&R years ago, but somehow I feel completely inadequate to being a C programmer. I think there is some kind of black art involved in memory management. I checked recently and it seems K&R doesn't even talk much about memory management. I just wish to learn the current state of the art - what are best practices that have evolved since K&R?
whatever you do, make your examples bulletproof. even if it's not how you would normally write the code and it seems overly cautious, do your audience a favor and write the example that way anyway. if there are any buffer overflows, integer overflows, off-by-one's, signedness issues, failure to check return values of everything, use of typically insecure things like sprintf instead of snprintf, all of these problems…
I don't think the learner would appreciate the subtleties, and I don't agree that they'll learn anything from it. I can reinforce each lesson/problem you're describing one by one through the exercises, but a new person simply wouldn't know good code if it slapped them in the face. Confer with Learn Python the Hard Way to get a feel for the aesthetic and technique I'm working towards. I don't want to write bulletproof…
What I really miss is some C book that teaches the modern approach to "object-oriented" C (as done in Gtk, Apache, CPython etc.). Actually many programmers (presumably with only passing knowledge of C programming) even actively proclaim that you cannot program in C in this style.
I'll teach function pointers, and might expose them to some style of OO C, but I haven't made any decisions on it. My approach is going to be relatively unflavored by the Macro Hell of other projects. I'd rather not instill those habits. They can learn that on their own time. I want the learner prepared to write clean sysprog code. That's it, the rest they can learn having been taught proper C and make their own styl…
whatever you do, make your examples bulletproof. even if it's not how you would normally write the code and it seems overly cautious, do your audience a favor and write the example that way anyway. if there are any buffer overflows, integer overflows, off-by-one's, signedness issues, failure to check return values of everything, use of typically insecure things like sprintf instead of snprintf, all of these problems…
Earlier quoted context omitted.
> I don't want to write bulletproof code, I want to teach them how and why to write bulletproof code. This confuses me. How can you teach someone to do something if you won't do it yourself? Reading your statement literally, you are effectively going to say, "This is how and why to write bulletproof code, but I'm not going to." The whole point of LxTHW is to learn by doing. If you're doing it wrong, they're learning…
Nobody's qualified to run a company when they do their first startup either.
You need to go get libraries for a lot of the stuff you'd normally use the standard library for in a more modern language. These libraries exist, and many of them are excellent, but because they're not built-in, people are less likely to use them. This is especially dangerous in C, because it requires so much work to do anything even vaguely complex.
edit: That came off as saying "Teach some libraries". What I really mean is "Teach people to go find libraries."