what is difference between std::unique_ptr V/s std::make_unique ?

SGaist

Hi,

Unlike new, make_unique is exception safe.
No cleanup is necessary if make_unique is not evaluated.

As for your code: why are you creating a unique pointer out of a stack based variable ?

Qt embedded developer

@SGaist Becuase the scope is within that main() so i have used that way.

In response to your question " My ClassName is only and only allowed to to call in main(). and not out side of it. And also I don't want any type of pointer error or freeing it manually so. i used it."

But i want to know all my question answer one by one. So if you give the explanation then it will help me next time what to use and what not to use.

SGaist

@Qt-embedded-developer the answer is basically: don't use 1 for the reasons given in my answer.

That said, you should really learn the use cases that comes with it. Using unique pointers is not a silver bullet. Especially in the case of Qt where there's the parent-child relationship paradigm.

JoeCFD

@Qt-embedded-developer said in what is difference between std::unique_ptr V/s std::make_unique ?:

std::make_unique

I guess there is no difference between line1 and line2.
std::make_shared was introduced in C++11, but std::make_unique was not.
If you use C++ 11, you can use only line 1, but not Line2.
Line2 was introduced in C++ 14. Therefore, from C++14, Line1 and Line2 are same.
Line2 is preferred since it is consistent with make_shared.

As @SGaist pointed out, auto classNamePtr = std::make_unique<ClassName>(&app); can be fatal.

kshegunov

@JoeCFD said in what is difference between std::unique_ptr V/s std::make_unique ?:

Line2 was introduced in C++ 14. Therefore, from C++14, Line1 and Line2 are same.

In this example yes, but not in general. Consider this:

class A;
int g() { throw 0; }
void f(std::unique_ptr<A> a, int p);

which can be used safely like this:

f(std::make_unique<A>(...), g());

while this may leak depending on how the compiler evaluates the arguments (which is unspecified):

f(std::unique_ptr<A>(new A()), g());

JoeCFD

@kshegunov I normally avoid passing any unique pointer in a func. If I have to, I prefer to define it as a shared pointer since it does not cost anything and why I look for trouble.

kshegunov

@JoeCFD said in what is difference between std::unique_ptr V/s std::make_unique ?:

If I have to, I prefer to define it as a shared pointer since it does not cost anything and why I look for trouble.

That's up to you, but keeping everything in std::shared_ptr, just because it's easy (for some definition of easy), is a rather lazy way of programming. There is a significant semantic difference between the two.

SamiV123

@JoeCFD

you pass unique_ptr to a function when you want to transfer the ownership of the object contained inside the unique_ptr to the callee.

Using a shared_ptr is rarely the right choice.

If you don't transfer the ownership use a raw ptr or reference.

JoeCFD

@kshegunov I am lazy indeed now. Will study more on std::unique_ptr

JoeCFD

@SamiV123 I see your point and will try to find some use cases.

Qt embedded developer

@JoeCFD said in what is difference between std::unique_ptr V/s std::make_unique ?:

As @SGaist pointed out, auto classNamePtr = std::make_unique<ClassName>(&app); can be fatal.

Can you elaborate this thing because why it can be fatal ?

JoeCFD

@Qt-embedded-developer app looks like using stack(not heap) memory. when classNamePtr is cleared, it will try to destroy &app and your app will crash likely.