[gnu]

I didn't enjoy this book, to be blunt. K&R still holds up as an interesting read, despite it not being updated to latest ANSI C standards. It is probably not a good first book.

A few C books I like:

  * C: A reference manual.
  * C: Interfaces and Implementations.
  * Deep C secrets.
  * C: Traps and Pitfalls.

[neuland]

I can also recommend Deep C Secrets. For me, a lot of C didn't really click until I read that book. In particular, having mainly done Python and other very high level languages up until that point, this book's discussion of pointers and memory were what got C to finally click for me.

[norswap]

An explanation of why you didn't like it would be more helpful.

[gnu]

Sure, but that is meant as a personal thing and not meant as a general statement. Everyone should evaluate whether the book (any book) works for their needs.

The main reason is that, it was a very dry read with various rules and syntax etc and I got bored looking at it quickly. It almost felt like I am reading an abridged version of the standard itself. The exercises didn't appeal to me much.

I didn't mean to dis the efforts of the author at all. There is no other book that covers the modern parts of the standard well. I am not aware of any other C book that covers the wide chars than this book.

[rtkaratekid]

I had the same experience with this book. I set out as an intermediate C programmer and ended up just bored to tears with things I felt were obvious and frustrated that questions about “real” C code were not being answered. Also the exercises were... very involved for just trying to learn potentially simple points. I ended up giving up on the book for now, maybe I’ll pick it back up later or I’ll peruse your list.

[sumtechguy]

I used k&r as my first C book. You can learn C from it. However it does teach a C that is not really used in the wild. Specifically function definitions and tri-glyphs. Its memory management is kind of hand wavy and it does not stress enough the importance of getting the types right (like the nightmare of printf). Both of which can cause memory issues very quickly. If you start with that book I would recommend one of those others to go along with it. Using C is easy. Getting it right takes time, practice, and a few stubbed toes.

[gnu]

I too learned C from K&R and really loved it. I did not have any other thing to do and there was no internet and no one telling me that C is bad. Nor was I aware of other cool languages. I did not even have a computer at that time, so I wrote most of the exercises on paper. Later my father bought me a 486DX66 and I typed in most of the programs in the book. Those were fun times!

[dmlorenzetti]

Not the OP, but for what it's worth, the overall flow of the book just didn't work for me.

"Modern C" takes a staged approach, going through

  + Level 0 Encounter
  + Level 1 Acquaintance
  + Level 2 Cognition
  + Level 3 Experience

This sounds like an interesting organizing principle, but in practice it is implemented quite rigidly, and produces, in my opinion, two serious weaknesses.

First of all, organizing by levels of detail, rather than treating individual topics in depth all at once, means that a fair amount of related information gets spread around the book.

This might be OK if the book had a comprehensive index, or consistently used forward-references to point the reader to a detailed discussion, but the book is generally weak in these sorts of cross-references.

For example, suppose you want to look up formatting strings for use with `printf()`. The index (I am looking at the Manning version) lists exactly one entry for `printf()`, which is on page 8 -- and the actual text there just mentions basically that `printf()` is a function that exists.

You could also look up "format", which gives one reference, to page 5, where the term is introduced but hardly even defined. The index does have more entries for `snprintf()` and `sprintf()`, if you happen to think to look for those. But after you play this game for a while, it becomes clear that the index takes a quite mechanical view of these functions, content to list locations where the function gets called out in the text, but without any great concern for where they are discussed as a cohesive collection of related functionality.

To me, this levels-of-experience approach makes sense for some things, like deferring discussion of threads, and setjmp-longjmp, till later chapters. That's why I say that the book errs by sticking to the game plan too rigidly.

The second major shortcoming of this rigid levels-of-experience approach is that the book delays discussing pointers for a long time. They aren't really taken up until chapter 11. Literally the book doesn't show a basic "swap" function until page 170. This means that a lot of code examples that come before chapter 11 do quite a dance to avoid using pointers.

When, finally, pointers are discussed, I felt that the text was somewhat lackluster. There is nothing wrong with it, but if this chapter was a blog post by some random C programmer, and got posted to HN, I doubt it would garner a lot of upvotes by enthusiasts saying it was the best description of pointers they had ever read.

Thus it had an anti-climactic effect for me -- I expected that deferring the discussion of pointers for so long would have some kind of pedagogical payoff, but there wasn't anything to it that, to me, justified putting it off for so long.

I had a few other problems with the book, but nothing that, by themselves, would keep me from recommending it.

I might recommend the book to somebody who already knows C, and wanted a deep dive on certain topics. However I would steer a beginner away from it.

Somebody else on this thread mentioned another new entry to this field, "Effective C" from No Starch Press. I am in the middle of this one, and so far like it a bit more (though I am not yet a full-throated enthusiast for it). I would note that "Effective C" introduces a swap function on page 16. That would be wildly premature to the author of "Modern C", but in the end I think it will serve the beginning reader somewhat better.

[dhosek]

I learned C from K&R. It was lent to me by an English teacher (!) from my high school and I can still recall the smell of it (stale coffee and cigarette smoke). C was my fourth language after BASIC, Pascal and 6502 Assembler.

[kyting]

Also P.J. Plauger's The Standard C Library

[jokoon]

C11 or c18 dont bring a lot. I wish they did, but they don't.

[brandmeyer]

I use C11 atomics pretty regularly. While lock-free data structures are tough to get right, there are other uses of atomics that are easy. For example, portable lock-free multithreaded statistics counters.

[beefhash]

Indeed, C11 and C18 don't bring a lot. I'm glad that they don't because backwards compatibility and roughly predictable development of the language is important to me.

[gnu]

I have been meaning to learn the Plan 9 dialect of C but haven't gotten around to it.