11

HI,

I have this query about smart pointers.

I heard from one of my friends that smart pointers can almost always replace raw pointers. but when i asked him what are the other cases where smart pointers cannot replace the raw pointers,i did not get the answer from him.

could anybody please tell me when and where they cannot replace raw pointers?

4
  • If your friend made an argumentation, he should have proved it with at least one example. More so after you asked for it. Commented Apr 7, 2010 at 14:19
  • 1
    @Daniel He should have proved it rigth with all the examples. Commented Apr 7, 2010 at 14:26
  • I he could not tell you in which cases he would not use a smart pointer "can't" probably just meant "don't want to". Commented Apr 7, 2010 at 14:39
  • I agree with your firend. But situations were smart pointers can't be used are not going to be generic they will be specific situations that you will not be able to think up ahead of time. Its like the argument "All swans are white". Are they? Show me a specific instance where they are not white. (For a European this was impossable to prove false). Until the first European went to Australia and found a specific situation where it was not true. Commented Apr 7, 2010 at 17:53

7 Answers 7

11
  1. Passing pointers to legacy APIs.
  2. Back-references in a reference-counted tree structure (or any cyclic situation, for that matter). This one is debatable, since you could use weak-refs.
  3. Iterating over an array.

There are also many cases where you could use smart pointers but may not want to, e.g.:

  1. Some small programs are designed to leak everything, because it just isn't worth the added complexity of figuring out how to clean up after yourself.
  2. Fine-grained batch algorithms such as parsers might allocate from a pre-allocated memory pool, and then just blow away the whole pool on completion. Having smart pointers into such a pool is usually pointless.
Sign up to request clarification or add additional context in comments.

8 Comments

@David, because there's no point, since you know you don't own the elements of the array (you're just traversing it) and coordinating with whoever owns the array would be very complicated. Besides, it might be a stack-allocated array requiring no memory management at all.
I believe that smart_ptr allows you to overload the function which cleans up the memory. Hence, it's quite concievable that a memory pool would work just fine with a smart_ptr as long as your clean-up function was properly coordinated with your creation function.
I find 1 and 3 straw men. On 1, most smart pointers have some sort of get, so you can still pass the contained pointer. And 3 isn't even a situation that matters. That's like saying "4. An integer. 5. A float." etc for each type. It just doesn't apply. And 2 is solved with a weak pointer.
@Marcelo: The question was things you can't do with smart pointers, not situations where smart pointers aren't useful.
@David, @GMan: in which case saying "there is nothing you can do with a raw pointer that you can't do with a smart pointer, because a smart pointer can return a raw pointer, and you can use that" rather misses the point IMO. Surely this is a question about what raw pointers are needed for, not a question about whether you can shove a smart pointer into some context where it doesn't help. I'm sure you can, but why would you?
|
4

An API that is going to be called from C, would be an obvious example.

Comments

3

Depends on the smart pointer you use. std::auto_ptr is not compatible with STL containers.

Comments

3

It's a matter of semantics:

  • smart pointer: you own (at least partly) the memory being pointed to, and as such are responsible for releasing it
  • regular pointer: you are being given a handle to an object... or not (NULL)

For example:

class FooContainer { public: typedef std::vector<Foo> foos_t; foos_t::const_iterator fooById(int id) const; // natural right ? }; 

But you expose some implementation detail here, you could perfectly create your own iterator class... but iterator usually means incrementable etc... or use a pointer

class FooContainer { public: const Foo* fooById(int id) const; }; 

Possibly it will return NULL, which indicates a failure, or it will return a pointer to an object, for which you don't have to handle the memory.

Of course, you could also use a weak_ptr here (you get the expired method), however that would require using shared_ptr in the first place and you might not use them in your implementation.

Comments

2

interaction with legacy code. if the api needs a raw pointer you need to provide a raw pointer even if once its in your code you wrap it in a smart pointer.

Comments

1

If you have a situation where a raw pointer is cast to an intptr_t and back for some reason, it cannot be replaced by a smart pointer because the casting operation would lose any reference counting information contained in the smart pointer.

Comments

1

It would be quite hard to implement smart pointers if at some point you don't use plain pointers.

I suppose it would also be harder to implement certain data structures with smart pointers. E.g freeing the memory of a regular linked list is quite trivial, but it would take some thought to figure out the combination of owning and non-owning smart pointers to get the same result.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.