This situation is why there is "hello world"; that program seems trivial but actually has important implications; for instance, that your environment works, that you know how to feed programs to the compiler, that you can actually run the output.<p>I never took "hello world" seriously until I started doing embedded systems work; it's now an extraordinarily important tool for me (I work an anomalously weird number of different environments).
I learned C by reading K and R and doing the book's exercises . . . on paper. At the time I didn't have access to a C compiler, so I wrote them all out in a notebook. A month later I got a job at a shop that was running Unix, and got the chance to type my programs in and try them.<p>I had a lot of things wrong. It took me a while to understand the difference between control-D and EOF, for instance (how embarrassing). But the 30 days I spent without a compiler made me <i>think</i> about program behavior.<p>I'm not saying this is a great way to learn a language, but it can be done.<p>I keep hearing people complain about K and R being "a terrible book." For me it was perfect: pragmatic, succinct, with great examples and good exercises.
Where to begin when learning C? Start at <a href="http://c.learncodethehardway.org/" rel="nofollow">http://c.learncodethehardway.org/</a>. It's going to be tough to top Zed Shaw's approach. The best way to learn code is by writing code.
I think I have some ingrained fear of making errors, from the days where a simple error might cause your program to chew through your whole hard drive. Actually I don't know if that was ever the case, but that's how I felt.<p>Anyway, the hardest step for me in learning a language is when I take some running code and make one change to see what happens. Once I get in the swing of it, it gets much easier, but that first step is still hard to do.
In order to for people to really understand C and be proficient in it very clearly, I always recommend that they learn the basics of programming (memory, basic types, looping structures and array manipulation) in a simple assembly language such as 6502. This helps immensely with understanding pointers and deciphering the many cryptic C compiler messages.
Install Valgrind. It makes error messages a lot less cryptic (my #1 problem with C... not that's it's limited to C). If you don't get proper feedback, it's not learning, just banging your head against the wall.
Currently, I'm learning Python and have been learning it for over a year now. I've been thinking about moving to C as my next language. Is this a good idea? I'm eventually going to want to learn C++, but I'm not going to learn Java until I have to. Also, what are some really good C learning resources? I know there's K&R and learncthehardway.org
I thinks this is a good approach. Checking most of possible exceptional cases while following regular learning course.<p>Errors = safety nets are usually the main reason to make stiff learning curve. This would be a great help for them.
As other people said earlier, reading existing code is great, when you have good sources. I'm an almost noob in C, and currently reading Ian Piumarta sources[1], I find they're superb in presentation and design.<p><a href="http://piumarta.com/software/" rel="nofollow">http://piumarta.com/software/</a><p>[1] mostly for maru, his lisp system, but even tty2html (ascii control -> html) is very clean and elegant.
This is stupid. You should learn C properly (know how to avoid undefined behavior) or not at all. Exception if you're doing something that can tolerate remote code execution.
Actually the message quoted complains about the lack of _main not main, so the rest of this post is a huge overinterpretation. _main is IMO some windoizm connected to the use of WinMain for GUI apps.