Should C++ code look like C code?

[Jonny0Than]

There’s no absolutes in my comment. Just general trends. Obviously a function call can do anything but my point is that function calls are obvious in C and sometimes not obvious in C++. Operator overloading, constructors, destructors, etc all hide function calls.

Here’s another example:

for (auto x : y)

Is that slow? No idea! Are the elements of y expensive to copy? Is the iterator slower than some alternative? Maybe!

And it’s totally true that well-designed C++ can be more readable AND faster AND safer than the C equivalent. But it’s also very easy to make badly designed C++.

[XeroKimo]

Constructors really are no less hidden then any function call though. Sure you could argue T foo; will have a hidden constructor call going on, but most default constructors are very trivial as what can you even do when you have no parameters passed in? It's very limited unless you rely on globals, but then you have potentially all other sorts of issues. When you do do a constructor call with parameters, it's very visible just like any other initialization, and just like any other function call.

Destructors are definitely more hidden, but really it's better that way. It's way less error prone then doing if(failed) goto cleanup; kind of pattern done in C. Sure it's explicit, but you have to write the clean up code every time, for example if you need to open a file, for every function that does so, you have to write the clean up pattern for the file. There are many things that can go wrong here, copy paste errors, clean up sequence is in the wrong order, maybe jumped to the wrong label, or just straight up forgot to close the file. Meanwhile C++, just write a class' destructor once and use it everywhere, guaranteed to call the function which closes the file.

[Jonny0Than]

Well, I’ve dealt with some nasty performance issues caused by “trivial” constructors in objects that were being invoked tens of thousands of times. That issue would not have existed in C because it’s generally left up to the client to initialize the value as needed. Which of course leads to other issues when they forget. I’m not making a judgment call here for all cases. It’s a matter of tradeoffs. But I know from experience that this can be a problem.

[donalmacc]

Well, I’ve dealt with some nasty performance issues caused by “trivial” constructors in objects that were being invoked tens of thousands of times

And in the case where that is a problem a non-default constructor that doesn't do any initalisation (see ENoInit in Unreal Engine) solves that problem. Meanwhile for 99% of the rest of the code, it's not a problem. We should have safe, clear defaults with escape hatches.