I learned C a while back, and don't regret the time spent doing so at all. This is how I'd recommend going about it: * Everyone is going to recommend K&R, which is fine. Find a copy of C Interfaces and Implementations as well--very good implementations with explanations of standard high-level structures. * Read source. SQLite's source, for example, is very well written and documented, and they actually have a version…
Ask HN: Learning C
51–60 of 66 posts
Re: Ask HN: Learning C
#52K&R et al. are fine, but I'm a particular fan of two slightly oddball, but great, books about C:
1. van der Linden's Deep C Secrets. Short of implementing a C compiler yourself, reading this book is the surest path to completely understanding some aspects of the C linkage model, and the distinction between arrays and pointers. It's also entertainingly written, which always helps.
2. The Lions Book, an annotated source listing for the Unix v6 kernel. The subject matter is one of the most beautiful and influential programs ever written. This ~10k-line program is completely understandable in six weeks' study, a couple months' tops, yet it staked out almost all of the abstractions that still underly modern operating systems. It is also C's native environment: C was literally invented to write this program. And while it's dated in some of its peculiarities ("=+" where we'd write "+=", identifiers only being significant in the first 8 characters, no typedef yet, a lot more reliance on the register keyword, etc.), it's damned fine code, by any standard. Each page brims over with good, informed engineering trade-offs; the sweet spot may have shifted since the days of 128k core and 16-bit CPUs, but the thinking that goes into those trade-offs is mostly unchanged.
Re: Ask HN: Learning C
#53Re: Ask HN: Learning C
#541. In Which I Join The Choir You should definitely learn C: * You'll learn the memory hierarchy, which is probably the most important thing to know about performant software. * You'll get 100x better at debugging --- both because you'll have practice, and because most of the tools you use to debug C code work for higher-level languages (gdb is still a better Ruby debugger than Ruby's own debugger). * You'll be able t…
x86 is a convoluted horror. A lot of it makes no sense except in the context of backwards compatibility, which the documentation won't necessarily point out. I highly recommend picking up a microcontroller to learn on instead of a microprocessor. Microcontrollers are mostly self-contained systems, while microprocessors are just a small piece of the picture and have complicated interfaces to the rest of the system components.
I recommend picking something in the Freescale 68HC* family. The addressing modes and instruction set are fairly clean and the architecture is simple. Something based on ARM would probably also be straightforward to learn. Don't worry about choosing a 32 bit chip, 8 or 16 bit is fine. 8 and 16 bit chips are typically simpler and will still teach you the important concepts.
Spend a couple of weeks on this and your understanding of C will be easier to come by and more thorough.
Re: Ask HN: Learning C
#55Earlier quoted context omitted.
Indeed, the problem with C is just that. Once you understand how it works, you'll realize it's just a thin abstraction layer over assembly language. It really is just that simple. My last job was almost purely C, and what made C "scary" at times were: 1. naming conventions. I don't know why C programmers use the strange names that they do. 2. macros. C macros are a pain to read and follow. I hope things will be easie…
They use the strange names that they do because a function declared in C is declared everywhere in the whole program. They use strange names to try to stay out of your way; i. e. it would be really bad if two functions had the same name.
Re: Ask HN: Learning C
#561. In Which I Join The Choir You should definitely learn C: * You'll learn the memory hierarchy, which is probably the most important thing to know about performant software. * You'll get 100x better at debugging --- both because you'll have practice, and because most of the tools you use to debug C code work for higher-level languages (gdb is still a better Ruby debugger than Ruby's own debugger). * You'll be able t…
I violently disagree with not learning assembly. Absolutely learn assembly. Just pick anything else other than x86 assembly. After learning the basics of assembly you will never have any trouble understanding pointers or any of the "hard" concepts in C. x86 is a convoluted horror. A lot of it makes no sense except in the context of backwards compatibility, which the documentation won't necessarily point out. I highly…
ARM, PowerPC, and MIPS are all good choices if you've got appropriate hardware to play with. All three are nice, clean RISC architectures with plenty of registers and sane addressing modes.
Re: Ask HN: Learning C
#57http://www.cs.umd.edu/class/fall2005/cmsc212/
It starts off with the fundamentals then gets into some more advanced principles. In particular, check out the "Jan Plane's Lecture Outlines" link.
Re: Ask HN: Learning C
#58Chances are you already know C, but don't realize it. Java and PHP have mostly C syntax. All you have to do is substract objects and add pointers. Like rsheridan6 said, assembly helps. It's not necessary though, as long as you realize a pointer is actually a memory address and not something abstract like a reference in Java or PHP.
... and figure out how to deal with allocating and freeing things. Taken together, pointers, and manual memory management are a big chunk to bite off. The syntax isn't the problem, in other words.
The examples that come to mind are Forth and APL/K/J (all of which I've only dabbled in), but the reason they have such unconventional syntaxes is because they're conceptually very different.
Re: Ask HN: Learning C
#59Earlier quoted context omitted.
I violently disagree with not learning assembly. Absolutely learn assembly. Just pick anything else other than x86 assembly. After learning the basics of assembly you will never have any trouble understanding pointers or any of the "hard" concepts in C. x86 is a convoluted horror. A lot of it makes no sense except in the context of backwards compatibility, which the documentation won't necessarily point out. I highly…
I'd steer away from the really small microcontrollers, as they tend to be register-starved (and/or memory-starved!) enough that you have to make ugly compromises, particularly in the area of call stacks. :( ARM, PowerPC, and MIPS are all good choices if you've got appropriate hardware to play with. All three are nice, clean RISC architectures with plenty of registers and sane addressing modes.
Re: Ask HN: Learning C
#60Earlier quoted context omitted.
They use the strange names that they do because a function declared in C is declared everywhere in the whole program. They use strange names to try to stay out of your way; i. e. it would be really bad if two functions had the same name.
You're right that C's lack of namespaces makes for funky names. However, note that "static" functions are visible only within their compilation unit, which can bring some order to the madness.