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();
}
}
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.
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.
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.
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.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.