> unqie_ptr have overhead. It need to run its dtor etc

Technically it is correct, it causes an extremly light overhead due to the inability of the compiler to optimise a part of it.

In practice, even in HPC, I never notice it to have an impact ever.

And as an advise for any new C++ programmers: Please JUST use unique_ptr, everywhere, all the time...

Trying to manage the lifetime manually with new/delete in modern C++ is not worth the cost in 99.99% of the case. If the impact of unique_ptr is noticeable in your program, you are very likely in a realm where you should not even doing memory allocation anyway.

You're misinformed. Overhead is not about the running the dtor, unless you're willing to leak the memory in your code regardless of the smart ptr usage or not.

What the "overhead" of unique_ptr is usually attached to is the inability for a compiler to pass the unique_ptr as a value through a register but will instead have to use the stack (memory). And that even doesn't apply in the general case but _only_ for unique_ptrs holding an object with non-trivial copy-constructors or non-trivial destructors. This is due to the platform ABI and not the C++ compiler limitation.

Anyway, calling that an overhead is a far stretch and almost purely theoretical unless someone is able to measure the negative effect of such code transformation in the real-world codebase. And I say this as not particularly heavy user of smart pointers.

Also, many other codegen transformations will not fit into a very limited amount of ABI registers so should we argue about not using those as well?

In my opinion, this was only a "campaign" of Google trying to use a unique_ptr as a leverage to persuade the committee to accept their break-the-world ABI suggestion. We know how it all went.

Ah ok interesting I need to dig into this.

Ye well I knew the overhead was really small.