Yeah, me too. However, I think what we have to take into account in 2013 is that most aren't taking this route anymore. Chances are, more beginners today would be familiar with JavaScript, MATLAB, R, or
Python before picking up
C++. This results in having formed different predilections and different expectations.
So, essentially, I could stop at this point:
If there already is a user-friendlier feature with zero overhead, there's no reason to introduce beginners to what's unnecessary. And if they *do* need to, say, implement their own thread-safe memory pool (s.t. raw pointers may *actually* be necessary), they're not beginners anymore (and chances are they're still going to be better served by looking into Boost and/or TBB first).
This has pretty important implications on how are you going to teach the rest of
C++ and in which order:
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-1-how-to-revis/240003977
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-2-how-language/240004388
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-3-smart-pointe/240004805
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-4-what-makes-a/240005166
http://www.drdobbs.com/cpp/c-primer-5th-edition-part-5-core-languag/240005657
In particular, take a look at part 3 (and the implications on when and how to introduce copy constructors and copy-assignment operators) and part 5 (compare the string concatenation examples). A very common theme one can notice is the following (emphasis mine):
I've also been unfortunate enough to have seen too much code written by the C-first programmers, who just never knew when to stop, which might've influenced my opinion; some common issues:
- using C-style arrays for no good reason or for imaginary reasons (where, for instance, interoperability with C-APIs works often perfectly fine using std::vector instead of C-style arrays),
- writing sloppy code without expressing (and even thinking of) the ownership semantics (a code that doesn't express a distinction akin to how it's expressed by using
shared_ptr over
unique_ptr is simply poorly written, undocumented code -- note that I'd treat code slapping
shared_ptr all over the place similarly, for the same reason) -- which then often leads to relying on the implicit (and undocumented) assumptions and problems when they invariably get violated,
- perhaps even worse offenders are the poor souls who at some point got convinced that you somehow need pointers for dynamic polymorphism (I guess poor on-line tutorials are to blame) and never got this misconception out of their heads, polluting the codebase everywhere.
In short, and somewhat tongue-in-cheek:
http://klmr.me/slides/modern-cpp/