Hello guys, first post here and what a nice community you have 
I would like to ask your opinion about another new kid in the block, called "Jumping Into C++" by the creator of cprogramming.com. Would you recommend this book to a starter?
Looks pretty bad, to be honest:
- introducing C-style arrays and manual memory management with pointers before std::vector is a profoundly bad idea for a book that's supposed to be for a beginner.
- similarly, using all this cruft to implement a linked list instead of demonstrating std::list first is a similarly bad idea.
I someway agree on this. I do agree beginners really need to know about std::vector, std::list and smart pointers and use them in production code.
But I fully believe it is important to understand at least the basics of how the are implemented. I think beginner books SHOULD mention and teach users about raw pointers. Fact is they are still in code. I don't want to see a book just go "this is a row pointer, ok now use this." IMO if a beginner book doesn't properly teach pointers then it's missing something very important. Raw pointers still have some use and they are still used in code. You don't need to wait till late in your C++ career to learn them.
Though I guess it can be said what you want to do. OP wants to be an expert in C++ it sounds like he will need to know and learn raw pointers fast. If you go to school you will absolutely be implementing your own basic version of std::vector and std::list using raw pointers without being allowed to use any of the standard library.
I don't think anyone is disagreeing with you on this.
However, it's the order they are presented that is critical. If a text is rolling its own list before introducing std::list or using naked pointers before presenting smart pointers, it failed.
For the record a ton of books are pure fail, simply because they were started 20 years ago and the author is being lazy when updating,
Exactly, it's not about the content, it's all about the order.
IMO, beginners will be unable to discriminate between the cases when it's appropriate to use raw pointers and the cases when it's not (and, because they'd seen them first, they'll end up abusing them -- there's an unfortunate, persistent bias to assume that features introduced in the early chapters are somewhat "simpler", while in fact often the opposite is true). I think it's this instilling of bad practices from the start that's already a major problem on its own -- I have never seen a good "legacy-first" book for C++. Not a single one. And it's not just "IMO" -- this is what we often see in the "For Beginners" forum. I fell the same about "using namespace std" from the start.
As a matter of fact, I don't think I've ever encountered a book in which this was a problem:
"I don't want to see a book just go "this is a row pointer, ok now use this." IMO if a beginner book doesn't properly teach pointers then it's missing something very important. "
// Well, of course depends on what one means by "properly", since in my view this actually includes an extensive introduction to std::unique_ptr, etc. -- and, in this way, 99% of the books I've seen failed, and failed badly 
For instance, "C++ Primer" (which I think is the one percenter here), has you implement your own String class using specialized memory allocator operating on raw/uninitialized memory for performance, making use of placement new, etc. Here are two example exercises:
Exercise 13.44: "Write a class named String that is a simplified version of the library string class. Your class should have at least a default constructor and a constructor that takes a pointer to a C-style string. Use an allocator to allocate memory that your String class uses."
Exercise 19.2: By default, the allocator class uses operator new to obtain storage and operator delete to free it. Recompile and rerun your StrVec programs (§ 13.5, p. 526) using your versions of the functions from the previous exercise.
The thing is, these exercises are way later, in the advanced part of the book, after you've already become a productive C++ developer who has written several non-trivial projects (and has obviously used std::string a lot, so has a fairly good idea on how to solve these exercises with a well-designed program).
The other books? Sure, they'll talk about raw pointers, new/delete, etc. -- but most (all?) of them won't even get into placement new and specialized allocators (<--- which is exactly where you'd use raw pointers when, say, writing a game engine -- so this omission is all the more frustrating here, really) anyway, so they're all kind of useless.
At the same time, I see dozens of books with this problem:
"If a text is rolling its own list before introducing std::list or using naked pointers before presenting smart pointers, it failed."
And, unfortunately, I see dozens of beginners making simple, perfectly avoidable mistakes by overusing raw pointers and manual memory management, wasting time on debugging trivial errors -- all of this is completely unnecessary for someone who's just beginning the path of game development.
Unavoidably, later on too many of them become demotivated and complain that "C++ is complex" (not that it's wholly untrue, be back to this in a moment) and become discouraged from programming. While, in fact, you can introduce C++11 in a "simplified" way (simple / automatic / modern stuff first and foremost, complex / manual / legacy stuff later), akin to C#, if you just get the order right. The problem is that 99% of the books and, I think, 100% of on-line tutorials don't.
In my opinion, in this day and age, telling a beginning game programmer -- who's just trying to pick up C++ for the first time and really wants to make some games -- to learn raw pointers first is analogous to telling a comparable beginner using C# to start learning by delving deep into the uses of unsafe keyword. As in: not helping.
Why do I believe the order is important?
Because learning-by-doing is crucial!
Going through a book (let alone "reading a book") is merely a necessary condition, NEVER a sufficient condition (and I include doing the exercises in "going through the book" -- I don't think merely reading will make anyone a programmer, let alone a good programmer). In addition to going through a book, you have to create lots of mini-projects on your own, ideally corresponding to where you want to be -- so, for a gameplay programmer, lots and lots of (text-based for starters) mini-games. And you will be able to get there much faster if you can rely on things like std::vector from WEEK ONE. Any single day you spend on a book that talks about syntactical trivia (like wasting time on "const char *" vs. "char const *", and drilling through examples in the "exercises" that only really show that these are just different ways of spelling the exact same thing) takes you away from the goal of becoming a gameplay programmer.
Note how this also fits with the career progression in gamedev -- i.e., it's good to have an experience of a gameplay programmer using existing game engines (and libraries with things like std::vector) before starting to write your own game engine (with, say, your own custom allocators / memory pools, thread pools, etc. -- and that's assuming that rolling your own engine is what's best, which is not always the case) -- so, a book which introduces topics in the order optimized for this is going to be perfect, IMO.
So, the bottom line, in my view: any book that wastes time on introducing raw pointers and manual memory management before std::vectors is not good enough -- and ultimately useless (well, perhaps it can be placed under a broken table as a support or something ;]).
// On a side note, I have a *lot* of issues with how programming is often taught at schools/universities, but perhaps that's a topic for another rant... ;]
// Or, I'll just leave this link for starters: http://cacm.acm.org/magazines/2010/1/55760-what-should-we-teach-new-software-developers-why/fulltext
// And this snippet:
In many places, there is a disconnect between computer science education and what industry needs. Consider the following exchange:
Famous CS professor (proudly): "We don't teach programming; we teach computer science."
Industrial manager: "They can't program their way out of a paper bag."
