About smart pointers:
std::auto_ptr was added in previous C++ standards, and is now deprecated.
std::unique_ptr, std::shared_ptr, and std::weak_ptr are all new ones added in C++11 (and earlier drafts), and may not be available to you unless you are using the latest standard. If you are not using the latest standard, Boost has boost::shared_ptr, boost::weak_ptr, and etc... But you may already have them in the std::tr1:: namespace, as std::tr1::shared_ptr and etc... (I'm not sure how the 'tr' namespace works - it may require doing something to enable it with your compiler).

The point about smart pointers is you don't have to call 'new' or 'delete' manually. Instead of 'new', you use std::make_shared() to make a shared pointer, and then the return result deletes itself once the smart pointer goes out of scope. std::unique_ptr() was forgotten to be added to the standard, but will be patched in later, and you can add it yourself:
#include <memory>
//std::make_unique implementation (it was forgotten in the C++11 standard, and will be added later.
//Once it's added, I can just remove this from here.
template<typename T, typename ...Args>
std::unique_ptr<T> make_unique( Args&& ...args )
{
return std::unique_ptr<T>( new T( std::forward<Args>(args)... ) );
}

There is no std::make_weak() because weak_ptrs() are obtained from shared_ptrs.

std::unique_ptr - Manages an object on its own - it alone controls the lifetime of the object. When std::unique_ptr goes out of scope, the memory is freed.
std::shared_ptr - Manages the lifetime of an object, possibly sharing ownership with other std::shared_ptrs. When every shared_ptr pointing to the same piece of data goes out of scope, then the data is released.
std::weak_ptr - Doesn't manage the lifetime of an object, but points to data held by std::shared_ptr. When all the shared_ptrs go out of scope, then the data is released, and any weak_ptrs still in existence safely throw an exception if the data is attempted to be accesses (instead of unpredictable results).

These declare the intent of the coder better:
std::unique_ptr = I own this object, nobody else owns it _or_ uses it.
std::shared_ptr = I own this object, possibly with shared ownership (through other std::shared_ptrs), and possibly with shared use (through weak_ptrs).
std::weak_ptr = I don't own this object, I just use it.
Regular raw pointer '*' = I don't own this object, I just use it (only use if the pointer's lifetime is garunteed to be longer than the class containing it)

"With the stack, the default is: Clean, Safe, Fast." - Herb Sutter
With local function variables and member-variables, they are automaticly leak-safe and exception-safe. Their destructors are garunteed to be called no matter what, even if the class owning the member variable throws an exception, or if the function with the local variable throws an exception.

In C++, if you use the stack whenever possible, and smart pointers the rest of the time, you (almost) never need to manage the lifetime of an object explicitely.

If you need to optimize the code, then use new and delete and raw pointers, but encapsulate it in objects so that it can't possibly leak out for the end user programmer. But! Default to using the stack first, smart pointers second, and ideally raw memory management never. Smart pointers are very very compact and fast anyway, so 99% of the time, it's premature optimization. But 1% of the time, it is valid and needed.

That's what I meant convey to say by this line:
"std::unique_ptr, std::shared_ptr, and std::weak_ptr are all new ones added in C++11 (and earlier drafts), and may not be available to you unless you are using the latest standard." (Buried in a block of text)

Clang, GCC/MinGW, and Visual Studio 2010 are all using the latest standard (C++11) - which is why they support shared_ptr and unique_ptr. They don't support the standard 100%, but they do support the majority of it. ([size=2]Yes, MinGW supports alot of C++11 as well). They had prior support for some of the standard even before it was standardized, though with GCC/MinGW (and possibly the others) you had to explicitly enable it.

Thanks for clarifying though! I assumed (possibly incorrectly) that the OP would understand that more recent standard-conformance comes with more recent compilers.