Once you've adopted boost's smart pointers, is there any case where you use raw pointers?

Question

I'm curious as I begin to adopt more of the boost idioms and what appears to be best practices I wonder at what point does my c++ even remotely look like the c++ of yesteryear, often found in typical examples and in the minds of those who've not been introduced to "Modern C++"?

Answer 1

These days I've pretty much abandoned all use of raw pointers. I've even started looking through our code base for places where raw pointers were used and switched them to a smart pointer variant. It's amazing how much code I've been able to delete by doing this simple act. There is so much code wasted on lifetime management of raw C++ pointers.

The only places where I don't use pointers is for a couple of interop scenarios with other code bases I don't have control over.

Answer 2

I still use regular pointers in resource-sensitive code or other code that needs tiny footprint, such as certain exceptions, where I cannot assume that any data is valid and must also assume that I am running out of memory too.

Managed memory is almost always superior to raw otherwise, because it means that you don't have to deal with deleting it at the right place, but still have great control over the construction and destruction points of your pointers.

Oh, and there's one other place to use raw pointers:

boost::shared_ptr<int> ptr(new int);

Answer 3

If you have circular data structures, e.g., A points to B and B points back to A, you can't use naively use smart pointers for both A and B, since then the objects will only be freed extra work. To free the memory, you have to manually clear the smart pointers, which is about as bad as the delete the smart pointers get rid of.

You might thing this doesn't happen very often, but suppose you have Parent object that has smart pointers to a bunch of Child objects. Somewhere along the way someone needs to look up a the Parent for a Child, so they add a smart pointer member to Child that points back to the parent. Silently, memory is no longer freed.

Some care is required. Smart pointers are not equivalent to garbage collection.

Answer 4

I don't use shared_ptr almost at all, because I avoid shared ownership in general. Therefore, I use something like boost::scoped_ptr to "own" an object, but all other references to it will be raw pointers. Example:

boost::scoped_ptr<SomeType> my_object(new SomeType);
some_function(my_object.get());

But some_function will deal with a raw pointer:

void some_function(SomeType* some_obj)
{
  assert (some_obj);
  some_obj->whatever();
}

Answer 5

I still use raw pointers on devices that have memory mapped IO, such as embedded systems, where having a smart pointer doesn't really make sense because you will never need or be able to delete it.

Answer 6

I find the primary difference between 'modern' C++ and the old* stuff is careful use of class invariants and encapsulation. Well organised code tends naturally to have fewer pointers flying around. I'm almost as nervous swimming in shared_ptrs as I would be in news and deletes.

I'm looking forward to unique_ptr in C++0x. I think that will tidy away the few (smart) pointers that do still roam the wild.

*still unfortunately very common

Answer 7

Certainly any time you're dealing with a legacy library or API you'll need to pass a raw pointer, although you'll probably just extract it from your smart pointer temporarily.

In fact it is always safe to pass a raw pointer to a function, as long as the function does not try to keep a copy of the pointer in a global or member variable, or try to delete it. With these restrictions in place, the function cannot affect the lifetime of the object, and the only reason for a smart pointer is to manage the object lifetime.

Answer 8

I'm writing C++ that has to co-exist with Objective C (using Objective C++ to bridge). Because C++ objects declared as part of Objective C++ classes don't have constructors or destructors called you can't really hold them there in smart pointers.

So I tend to use raw pointers, although often with boost::intrustive_ptr and an internal ref count.

Answer 9

Not that I would do it, but you need raw pointers to implement, say, a linked list or a graph. But it would be much smarter to use std::list<> or boost::graph<>.

Answer 10

Just a few off the top of my head:

• Navigating around in memory-mapped files.
• Windows API calls where you have to over-allocate (like a LPBITMAPINFOHEADER).
• Any code where you're munging around in arbitrary memory (VirtualQuery() and the like).
• Just about any time you're using reinterpret_cast<> on a pointer.
• Any time you use placement-new.

The common thread here is "any situation in which you need to treat a piece of memory as something other than a resource over which you have allocation control".

Answer 11

talking to code that you didn't write is kinda a big deal. its not just windows and legacy.