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.
"Modern C" takes a staged approach, going through
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.