what's the point of auto_ptr & unique_ptr?

Question

I just can't understand the meaning of unique_ptr or auto_ptr, as we all know, once the parameter gets out of its scope, we won't get memory leaks. However, is it a better idea if I create the parameter on the stack rather on the heap. I don't see its advantage over normal parameters. If we really need to create parameters on the heap, then we must use new operator, right?

Here is a little code snippet:

class Base
{
public:
    Base()
    {
        cout << "Base::()" << endl;
    }
    virtual ~Base()
    {
        cout << "~Base()" << endl;
    }

    virtual void iPhone()
    {
        cout << "I'm iPhone5s" << endl;
    }
};

class Derive : public Base
{
public:

    Derive()
    {
        cout << "Derive()" << endl;
    }

    virtual void iPhone()
    {
        cout << "I'm iPhone 6" << endl;
    }

    virtual ~Derive()
    {
        cout << "~Derive()" << endl;
    }
};

void main()
{
  {

      auto_ptr<Base> ptr(new Derive());//a foolish idea to do so?
      ptr->iPhone();

      Derive d;//isn't it better?
      Base* base = &d;
      base->iPhone();
 }
}

Answer 1

It can help to look at std::unique_ptr and std::shared_ptr in the form of ownership instead of as pointers: std::unique_ptr when something can only have one owner at a time, and std::shared_pointer when something can be shared.

Note that since C++11 (which introduced the other smart pointers) std::auto_ptr has been deprecated.

Answer 2

I'm getting a lot of down votes for answering your question that is in the comment and not in the title. In the comment, you ask However, is it a better idea if I create the parameter on the stack rather on the heap. This is the answer for that question:

Automatic variables should always be preferred, but it has it is limitation. A reason why you might want to allocate memory dynamically that only lasts for the scope is when you want to create a large memory, the stack has a limited size and so you might want to create it on the heap if it might breach that size.

Answer 3

Forget auto_ptr. It is obsolete now, because of its unusual copy semantics. If you would like to have real smart pointers, use unique_ptr or shared_ptr.

Now, your question is: why use unique_ptr ? When you create an object A inside an object B, you could declare it as an attribute of B class, for example. It is on the stack, and you don't need unique_ptr. This is true, but sometimes, your object B must be initialized without the instance of A, because, for example, A is too big, or you don't use it. Thus, you must do dynamic allocation, and it helps to use unique_ptr to not avoid to delete your pointer.

Answer 4

Consider you have:

class A { };
class B : public A { };

A* factory(bool willBeA)
{
  return willBeA ? new A() : new B();
}

int main()
{
  //I want to get an instance of A or maybe B depending on a value
  bool val = false;
  unique_ptr<A> ptr { factory(val) }; //you need having a pointer to the returned value of A

  //do something

  //no need for delete

  return 0;
}

In this case, you cannot create an automatic variable to store A, because you actually do not know if an instance of A or B will be used.