Hacker News Reader

Comment by krychu | Hacker News Reader

The proper way to learn C is to get a good book, read it, and do exercises along the way.

Here’s an excellent book: C Programming: A Modern Approach, by King.

Avoid online tutorials, and know that there are many poor books on C, including the recommended here “Learn C the Hard Way”. It has factual problems; see under “Stuff that should be avoided” here: http://iso-9899.info/wiki/Main_Page

Note also, that unlike some other languages, C is not a language that you should learn by “trying things out”, due to the nature of “undefined behavior”.

Another recommendation would be to ask for CR on IRC.

Good luck!

View on HN

Since UB can be a bad beast to tackle while learning C and C++, I would suggest to frequently compare what you learn with cppreference.com, and check that you understand that what you think matches what the standard dictates. Cppreference is not the standard, of course, but is sufficiently similar and much easier to read.

If at some point you want to really become a master, then switch to the actual standard.

> Note also, that unlike some other languages, C is not a language that you should learn by “trying things out”, due to the nature of “undefined behavior”.

I disagree. You have to learn the ways in which things fail in any language you learn, especially a language like C.

The point is that you don't learn all the ways in which things fail in C by trying. At best, you learn the way in which they fail (or fail to fail!) on your specific platform/compiler/version/compiler options combo.

If you want to know how things can fail (or, what things can fail in unspecified ways), you have to do a bit of reading and no amount of trying and experimenting will conjure that knowledge.

There isn't a guide to learn how things fail on platform, compiler, version, options combo. Probably the only things that force you to systematically research and accumulate such knowledge is by writing a language VM in C or use C as an intermediate representation. Even writing a C compiler itself won't teach you that.

> There isn't a guide to learn how things fail on platform, compiler, version, options combo.

Yeah, that's the point. Chasing that knowledge is pointless. Instead, read the spec and find out what is legal and what is not. What is defined and what is not. Then you can stop worrying about how things fail and start worrying about not doing those things.

Trying c out with a known solid testing framework seems like a much more practical and useful way to start. Telling people to read a text wall before doing any practice at any task is a great setup for failure. Math doesn’t do that. Physics doesn’t do that. Chemistry doesn’t do that. Literature doesn’t do that. Philosophy doesn’t do that. Etc. and of those philosophy is almost the study of text walls. But the best philosophy courses tend to start with a Socratic dialogue which is basically live action philosophizing.

Well, we also have lots of historic evidence (nearly every application written in C ever) that traditional/intuitive teaching methods don't work for C.

All people have learned from the last 40 years of C is how to write ridiculously insecure applications.

Reading the standard may not be the optimal choice, or even the first choice, but common teaching methods are nearly guaranteed to produce crap results in the specific case of C programming.

I broadly agree. More so than any other other language, you cannot produce a good C (or C++) programmer by try-it-and-see alone. It's vital to have a grasp of the way the language is defined.

Point of disagreement: no amount of C expertise makes a hand-written C codebase safe. Vulnerabilities and undefined behaviour are often found even in code written by top-flight C programmers.

To me it's really both. Do one first, notice it works sometimes and you're not sure whether you should publish it (at that point, don't :) -- ) and then look at your own product through the lense of what you're learning. Eg. there are different kinds of UB and different problems it causes. There's a lot of entertaining literature and people in certain communities that can get you on the right track.

One of them was certainly this one: https://devblogs.microsoft.com/oldnewthing/20140627-00/?p=63...

Yeow, the format conversion has completely eaten the formatting on this poor blog.

This is readable: http://web.archive.org/web/20140629013829/http://blogs.msdn....

Oh wow, sorry for not looking into this properly. Thanks for the fixed link.

I’m always skeptical of telling people to not just try something out in programming. Yes, don’t just try to code up the next unix without knowing any c. But definitely getting your hands dirty isn’t going to instill any super bad mental/coding practices.

You can learn by playing around, but its very helpful to have a guide in the begining.

I had to start coding for work in C and without some good footing it was frustrating dealing with older code and creating new things with my very limited experience. (I had c++ which isn't the same.)

Having spent a week going a book and getting up to speed helped greatly and increased my enjoyment, reduced my frustration fwiw.

Reply on news.ycombinator.com