I also follow the "strong ownership" train of thought. I like to clearly delineate that "this class owns this member" when its appropriate.

I rarely use smart_ptr. If I do, I make liberal use of weak_ptr whenever I can so I can treat it like a handle to the object instead of increasing the reference count.

I use scoped_ptr all over the place. It shows obvious ownership. The only reason I don't just make objects like that a member is because you can forward declare them if they're in a scoped_ptr.

If I need a list of objects, I use ptr_vector. It's more efficient and has fewer side effects than using vector<smart_ptr>. I think you might not be able to forward declare the type in the ptr_vector (it's been a while), but the semantics of it make it worth it in my opinion. Basically if you remove an object from the list it gets deleted automatically. This also shows obvious ownership.

If I need reference to something, I try to make it a reference instead of a naked pointer. Sometimes this isn't practical (i.e. any time you need a reference after the object is constructed). Either way, references show obviously that you don't own the object, and if you're following shared pointer semantics everywhere else then naked pointers generally don't cause any additional confusion (especially if you follow a "no manual deletes" rule).

With this method, one iPhone game I worked on was able to only have a single delete call, and that was in the Obj-C to C++ bridge I wrote.

Generally I'm of the opinion that memory management is too important to leave to humans. If you can automate deletion, you should. If the overhead from smart_ptr is too expensive at run time (assuming you turned off threading support, etc), you probably should be using something else (i.e. a bucket pattern) to get your dynamic allocations down.

I also follow the "strong ownership" train of thought. I like to clearly delineate that "this class owns this member" when its appropriate.

I rarely use shared_ptr. If I do, I make liberal use of weak_ptr whenever I can so I can treat it like a handle to the object instead of increasing the reference count.

I use scoped_ptr all over the place. It shows obvious ownership. The only reason I don't just make objects like that a member is because you can forward declare them if they're in a scoped_ptr.

If I need a list of objects, I use ptr_vector. It's more efficient and has fewer side effects than using vector<shared_ptr>. I think you might not be able to forward declare the type in the ptr_vector (it's been a while), but the semantics of it make it worth it in my opinion. Basically if you remove an object from the list it gets deleted automatically. This also shows obvious ownership.

If I need reference to something, I try to make it a reference instead of a naked pointer. Sometimes this isn't practical (i.e. any time you need a reference after the object is constructed). Either way, references show obviously that you don't own the object, and if you're following shared pointer semantics everywhere else then naked pointers generally don't cause any additional confusion (especially if you follow a "no manual deletes" rule).

With this method, one iPhone game I worked on was able to only have a single delete call, and that was in the Obj-C to C++ bridge I wrote.

Generally I'm of the opinion that memory management is too important to leave to humans. If you can automate deletion, you should. If the overhead from shared_ptr is too expensive at run time (assuming you turned off threading support, etc), you probably should be using something else (i.e. a bucket pattern) to get your dynamic allocations down.

I also follow the "strong ownership" train of thought. I like to clearly delineate that "this class owns this member" when its appropriate.

I rarely use smart_ptr. If I do, I make liberal use of weak_ptr whenever I can so I can treat it like a handle to the object instead of increasing the reference count.

I use scoped_ptr all over the place. It shows obvious ownership. The only reason I don't just make objects like that a member is because you can forward declare them if they're in a scoped_ptr.

If I need a list of objects, I use ptr_vector. It's more efficient and has fewer side effects than using vector<smart_ptr>. I think you might not be able to forward declare the type in the ptr_vector (it's been a while), but the semantics of it make it worth it in my opinion. Basically if you remove an object from the list it gets deleted automatically. This also shows obvious ownership.

If I need reference to something, I try to make it a reference instead of a naked pointer. Sometimes this isn't practical (i.e. any time you need a reference after the object is constructed). Either way, references show obviously that you don't own the object, and if you're following shared pointer semantics everywhere else then naked pointers generally don't cause any additional confusion (especially if you follow a "no manual deletes" rule).

With this method, one iPhone game I worked on was able to only have a single delete call, and that was in the Obj-C to C++ bridge I wrote.

Generally I'm of the opinion that memory management is too important to leave to humans. If you can automate deletion, you should. If the overhead from smart_ptr is too expensive at run time (assuming you turned of threading support, etc), you probably should be using something else (i.e. a bucket pattern) to get your dynamic allocations down.

I also follow the "strong ownership" train of thought. I like to clearly delineate that "this class owns this member" when its appropriate.

I rarely use smart_ptr. If I do, I make liberal use of weak_ptr whenever I can so I can treat it like a handle to the object instead of increasing the reference count.

I use scoped_ptr all over the place. It shows obvious ownership. The only reason I don't just make objects like that a member is because you can forward declare them if they're in a scoped_ptr.

If I need a list of objects, I use ptr_vector. It's more efficient and has fewer side effects than using vector<smart_ptr>. I think you might not be able to forward declare the type in the ptr_vector (it's been a while), but the semantics of it make it worth it in my opinion. Basically if you remove an object from the list it gets deleted automatically. This also shows obvious ownership.

If I need reference to something, I try to make it a reference instead of a naked pointer. Sometimes this isn't practical (i.e. any time you need a reference after the object is constructed). Either way, references show obviously that you don't own the object, and if you're following shared pointer semantics everywhere else then naked pointers generally don't cause any additional confusion (especially if you follow a "no manual deletes" rule).

With this method, one iPhone game I worked on was able to only have a single delete call, and that was in the Obj-C to C++ bridge I wrote.

Generally I'm of the opinion that memory management is too important to leave to humans. If you can automate deletion, you should. If the overhead from smart_ptr is too expensive at run time (assuming you turned off threading support, etc), you probably should be using something else (i.e. a bucket pattern) to get your dynamic allocations down.