41–50 of 127 posts
Earlier quoted context omitted.
I hear you, I voted a few days ago for the C book and this is why I did (and I'm primarily a Python guy).
I am doing this precisely for you and everyone like you. I'm a professional python dev :)
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 disagree. If I'm learning a new language, I'm too busy worrying about the commas and semi-colons, not whether or not I'm using strcat or strncat. Worrying about overflows, signedness, etc. is something you do once you're more comfortable with the language. It would be nice to provide links to articles and books on why one should use snprintf instead of sprintf or what is integer overflow and how do you deal with it…
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 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. that is my point: your readers might not understand everything you're doing, so they're just going to copy and paste parts of it into thei…
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 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. that is my point: your readers might not understand everything you're doing, so they're just going to copy and paste parts of it into thei…
Earlier quoted context omitted.
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…
Why would you shy away from macros? Yes they are ugly, but they are an integral part of C and any system programming will rely quite heavily on macros, whether we like it or not. If you're going to cover macros, please make sure to explain how they work and the multitude of pitfalls as well as how to deal with them; which is to wrap each macro in parenthesis.
Best not to go there beyond explaining how and why not to, and leave it at that.
Order of operations is an example of something that bites people with macros. (ref/deref + macro has nailed a lot of professionals I know)
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. that is my point: your readers might not understand everything you're doing, so they're just going to copy and paste parts of it into thei…
[deleted]
Make sure you explain pointers well, the additional level of indirection introduced by them is usually hard to grasp for beginners. Show the relation between pointers and arrays. Offer some best practices on using pointers. Explain the most common caveats like buffer overflows, problems with null terminated strings or off by one errors.
C doesn't syntactically distinguish rvalues and lvalues, so this level of indirection often goes unnoticed. I strongly suspect this is why learning pointers is often hard: trying to grasp an additional level of indirection before having comprehended the first one is nearly hopeless.
[1] Variables are containers for values. This is isomorphic to a constant pointer to a mutable cell.
Why not base it on a project? If you want more people to do systems programming (I am assuming kernel and driver development), why not take something from http://kernelnewbies.org/ and turn it into a simple project or write a character driver. People will learn how to write code for the Linux Kernel, learn how to interact with that community and perhaps become more interested in systems development as a result, if th…
No, I disagree with most of this. A LTHW book covers just enough of the language that someone could then go learn the things you mention from another book. At the end you could lightly cover testing, but most people can barely get an editor installed. No way they can learn multi-threading, TDD, an entire project, and an RCS. It'd also dilute the focus of the book.