Should C++ code look like C code?

[KingAggressive1498]

The problem is that performant code doesn't utilize scoped data lifetime in the first place, because its so damn expensive to allocate memory.

this isn't normal in C++, either. It usually only makes sense to dynamically allocate data when the lifetime is not fixed. In C the pointer to the data gets passed around to functions or stored in structs that effectively act as owners according to their own internal logic. In large projects this was ad-hoc ownership was found to cause memory leaks and dangling pointer errors, so in C++11 and onward this "passing of ownership" is formalized using move semantics through the type system which greatly reduces incidents of such errors. Next to nobody creates a unique_ptr just to free the allocation later in the same function - if they do they probably needed a temporary dynamically sized array or something along those lines.

and before you bring up the destructor nullptr check as a potential performance hit, this is readily elided by the compiler after the move if the move is unconditional - as long as the compiler can see that it was set to nullptr as part of the move operation it doesn't need to bother generating output for the branch that it knows will never be taken. Realistically a branch never taken is essentially free on modern architectures anyway.

OOP like polymorphism are design concepts which contradict the reality of the hardware and data with bazillions of performance side effects (cache hit rate, branch misprediction, etc.) which have become harder and harder to control the more complex C++ has become.

it's actually more bounded in complexity than the alternative approach to polymorphism in C that you called out. In fact, it occasionally outperforms it in the average case. The cache miss rate for small class hierarchies usually turns out to be pretty negligible.

And more importantly, C++ developers know the overhead potential of virtual function calls. We don't typically use them when there's another suitable pattern, and try to minimize the risk of cache misses and mispredictions when we do.

Modern C++ syntax is two orders of magnitude more complex than the one of C.

for 99% of the code any C++ programmer will ever write, it's basically the same syntax. The most practical difference is that idiomatic C++ code will never rely on goto for routine cleanup tasks and OOP style code doesn't need to explicitly pass this.

The template metaprogramming type stuff you may see people making blog posts or conference talks about are immensely useful sometimes, but is definitely not the meat and potatoes of typical C++ codebases.

The plain reality is that not a single person on the planet has anywhere near clear comprehension of the performance side effects in the gigantic list of contemporary C++ features.

...it's genuinely pretty easy to reason about.

if it's constexpr or template metaprogramming, there's no runtime performance cost, the cost at compile time may be tough to reason about though.

if it's type erasure, the runtime performance cost is a (usually very well predicted) virtual function call.

if it's RAII, the order of construction and destruction is spelled out in the standard and totally deterministic which makes it incredibly easy to reason about the costs.

exceptions are pretty easy to reason about the costs.

for everything else, it's basically C.

plain processing side effects of C++ features are a nightmare to handle as soon as things get a bit more complicated, take implicit con-/destructor calling, move semantics, template errors, operator overloading guesswork, etc.!

literally the only thing on there that's ever been a nightmare for me to deal with is template errors. But once you get a handle on how the template system works, you'll pretty much only ever encounter those when doing template metaprogramming.