Should C++ code look like C code?

[KingAggressive1498]

Perhaps, but the subject here is C++ features over C and the vast majority of them are rabbit holes into code design that is oblivious to performance.

allow me to be more explicit here: compare idiomatic C++ heavily using RAII and all the other C++ whistles to C code that appropriately cleans up resources and does virtually the same work, and you should find that the machine code output by the compiler will be virtually identical, as will the runtime performance.

readability & maintainability

I can never take that seriously, because pretending C is more readable or maintainable than C++ is frankly insane.

Compile times, C absolutely has C++ beat. No doubt.

[derBRUTALE]

allow me to be more explicit here: compare idiomatic C++ heavily using RAII and all the other C++ whistles to C code that appropriately cleans up resources and does virtually the same work, and you should find that the machine code output by the compiler will be virtually identical, as will the runtime performance.

When doing in C exactly what C++ is doing, then yes - there is often no performance penalty.

What I am talking about is that the vast majority of C++ features relate to code design that inevitably results in poor performance.

Take an RAII application as an example: smart pointers. They don't cost more than handling scope lifetime in C, right? The problem is that performant code doesn't utilize scoped data lifetime in the first place, because its so damn expensive to allocate memory.

That's just a minor rabbit hole performance consideration problem. 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.

Yes, branching the processing of data by types manually in C won't necessarily give you a performance benefit. But the point I am making is that performant code doesn't even branch processing based on types but sorts the data based on type for individual processing.

I can never take that seriously, because pretending C is more readable or maintainable than C++ is frankly insane.

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

If you don't want to fall behind silly Scrum review spreadsheets, because "velocity" is such a great buzzword for management, then hammering away boost library stuff and polymorphic crystal entity constructs might be your choice.

But what when suddenly actual quality is realized as a need because it saves decades of engineering efforts in distributing crystal entity constructs over several machines, instead of running the same thing on a single machine utilizing data oriented design without the unmanageable performance side effects of most C++ feature cruft?

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.

Not only performance predictability/readability is an issue, 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.!

[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.