> probably avoid introducing pointers until very late
Introduce shared_ptr<> early, explain how actual pointers should pretty much only be used for compatibility with old-style libraries or if you're the one writing the standard library.
Introduce shared_ptr<> early, explain how actual pointers should pretty much only be used for compatibility with old-style libraries or if you're the one writing the standard library.
So, please, don't push shared_ptr as a magic one-size-fits all solution, especially to newbies. There's a reason why reference counting is not used everywhere.
With C++ you must remember that it's using pass-by-value semantics by default, which is very different from pass-by-reference semantics of other (syntactically similar) languages (like Java). Using shared_ptr's will not get rid of this fact and makes things even more complicated.
In fact, I have a very hard time to find _any_ use for shared_ptr's in my C++ projects. scoped_ptr's and ptr_containers have proven to be more useful.
One of the things I like about C++ is that it gives me choices and I still use raw pointers sometimes but shared_ptr removes a lot of manual memory management noise and makes it much easier to write robust, correct, exception-safe code.
That said, shared_ptr isn't a solution to everything. Sometimes scoped_ptr (called unique_ptr in tr1) or intrusive_ptr is a better tool. Often if you don't want to share or transfer ownership, passing around a raw ptr or reference is even better and the only option if you want to work with embedded structs (but the newed memory should still be owned by some RAII smart pointer even if it gets passed around as a bare pointer)