Go get a copy of accelerated C++ by Koenig and Moo.

You will learn all of the STL you need.

As far as pointers go, if you do c++ properly you should never need to call new or delete. Between the container classes and the auto_ptr type (and boost's smart pointers), you should be fully covered.

Also, see this list. As it says, read them mostly in order. You might need something down the list before you get to it.

frob.

The drawback with auto_ptr is that you cannot safely put it into an stl container. The advantage of using auto_ptr is that it saves you in situation where exception handling code might bypass the code to delete the pointer. It provides a very simple but effective safety net. It's got it's uses, but it's not the magic bullet.

I'll second Koenig&Moo -- it's the only introductory C++ book that I know that teaches you to code C++ and not C-with-classes.

Quote:Original post by frob
As far as pointers go, if you do c++ properly you should never need to call new or delete. Between the container classes and the auto_ptr type (and boost's smart pointers), you should be fully covered.

New is still nessesary for polymorphism and non-auto lifetimes, but agreed -- you should never be calling delete ( or fclose() or closesocket() or ... ) except in the destructor of a RAII class.

Once nice use of auto_ptr is returning from a clone() function -- if they ignore it or don't explicitly do something stupid, then it wont leak. I also like it for accepting pointers, because a function taking an auto_ptr by value makes it very clear that you're taking over the lifetime management of that object.

As for containers of polymorphic objects, also consider The Boost Pointer Container Library. You can treat a ptr_vector<Base> almost liek a vector<Base&> -- the extra dereference ( an implementation detail of storing pointers for polymorphism ) is done for you. It also deletes and clones where nessesary so there's no reference counting needed.

Of course, if you're keeping handles to the objects in your container, you might still want a std::container of shared_ptrs so you can have weak_ptr handles.

Quote:Original post by LilBudyWizer
Particularly whether it wouldn't be better to limit it to scenerios where a single delete statement wouldn't handle freeing the object properly or for which it might not be clear who is responsible for freeing the object.

I don't use delete anymore, I exclusively use boost::scoped_ptr for when I would do new/code/delete, and boost::shared_ptr when the pointer needs to be passed around or stored. std::auto_ptr has it's places but I don't use it unless it is for some reason difficult to use the boost ptrs, or if a dependency on boost is unacceptable.

Similarly I use boost::*_array and boost::mutex::scoped_lock. Basically anywhere you have to call something at the beginning of a function and at the end, use a "smart" or scoped solution - it's mostly exception-safe and will free you to insert return's anywhere in the function.

I often use std::auto_ptr as the return value from functions (though Washu dislikes that practice). Otherwise mostly I use boost::shared_ptr.

For general use I think the Boost smart pointer library is much better than std::auto_ptr. Of particular interest are both the enable_shared_from_this class and the ability to specify custom deleters for your pointer. This latter is particularly useful. For example, you can keep a COM interface pointer inside a shared_ptr, and have it call the Release() member function whenever it goes out of scope. I find this a remarkably convenient way of dealing with COM objects because I absolutely hate their manual reference counting. Between boost::shared_ptr and boost::scoped_ptr, the only real use for std::auto_ptr is for when you want to enforce single ownership but not noncopyable semantics, which really isn't that often in my experience. I think its best use is mentioned up above by me22 in that passing a std::auto_ptr to a class makes it very clear that the class intends to take over lifetime ownership of that memory.

Overall though, I'd definitely recommend using smart pointers wherever possible. I, like some who have posted before me, almost never actually use delete anymore when I'm programming in C++.

Quote:Original post by Bregma

...
#include <memory>

class X;

class C
{
public:
void f() { m_x = std::auto_ptr<X>(new X); }

private:
std::auto_ptr<x> m_x;
};


This has the advantage that you don't need to write your own destructor to delete m_x, the default destructor will do the right thing, ...

No it won't, in this case. It will ONLY be deleted properly if the class has a non-default destructor. Otherwise, the forward declaration in the header is not enough information for the compiler to create a destructor of the member object. I got bit by this a long time ago. Won't make that mistake again.

For another interesting thing you can do with pointer wrappers, you can look at: http://www.codeproject.com/cpp/TwoThirdsPimpl.asp.

David