[Pombal]

You are describing 'zero cost abstractions'. Except that they are anything but zero cost. Game developers and low level programmers shy away from them because of their impact in compile and build times, debug build performance and stack trace bloat, increased cognitive load, reduced refactoring ability. Even std::unique_ptr has runtime costs in release builds that a raw pointer does not.

In game development performance is a feature and anything that makes performance and memory usage less deterministic is frowned upon, like a GC. But iteration times are still paramount and things that make compile, load and link times longer and make it more difficult to debug are also frowned upon. Yes, we'd like to have our cake and eat it too :)

[einpoklum]

> You are describing 'zero cost abstractions'

No, that's a different (and orthogonal) concept. The point is that in C++ "you don't pay for what you don't use" - whether it's a cheap or an expensive abstraction, if you don't use it then its overhead won't affect your code's performance.

However, many of the C++ abstractions are zero-cost in many common cases.

> Game developers and low level programmers shy away from them

No, they don't. They shy away from abstractions which are too expensive; or whose scope of optimization doesn't fit the game's use; or which don't combine well with out-of-standard-library code used in the game etc.

But game developers use _lots_ of C++ abstractions; and fancy non-C-like C++ features.

[jcelerier]

> Even std::unique_ptr has runtime costs in release builds that a raw pointer does not.

O RLY ? https://gcc.godbolt.org/z/QhbUjI

[Pombal]

Yes, really. It's fine for simple types but for more complex types in more complex situations, you pay the price.

Unique pointers carry around not just the type but also a default deleter, if you provide one. That deleter has to be copied around, checked for nullptr before execution and set to nullptr when ownership changes.

For even more examples of this have a look at this talk when it comes out: https://cppcon2019.sched.com/event/Sfq4/there-are-no-zero-co...

[rcxdude]

Only if the deleter you define has any state, which is very rare and in that case you would need to copy that data around anyway...

(for example: https://gcc.godbolt.org/z/mU7hub)

[pingyong]

It's pretty stupid to compare a unique_ptr with a deleter that contains state to a pointer - obviously those two things are completely different and the unique_ptr contains way more information.

[abainbridge]

How would I create the pointer to int in the unique_ptr case without initializing the int? I tried this: https://gcc.godbolt.org/z/SfVxzU

I expect there is a way, just I don't know it.

[jcelerier]

See the docs : https://en.cppreference.com/w/cpp/memory/unique_ptr/make_uni...

For C++ < 20 replace `std::make_unique<int>()` by `std::unique_ptr<int>(new int)` (which with all explicit uses of `new` can end up not being safe in some cases (in that case, only if you've not enough memory to allocate an int which should not really be a common occurence...)

For C++ >= 20 you get std::make_unique_default_init which does that properly.

[einpoklum]

Have created a Stackoverflow question focused on this point:

https://stackoverflow.com/q/58050872/1593077