I'm having a hard time making sense of this page. Why is this comparing fastest implementation with slowest implementation? Why is the metric busy time/least busy? Why is C++ so much better than C?
But yes, some of these do provide hints for the compiler, e.g. constexpr, ownership semantics per unique_ptr. There's nothing stopping a human from writing equivalent C, so my suspicion is that the performance gap is primarily due to the benchmark implementation.
My experience is that C++ that's written for performance will often prefer the use of templates over inheritance since the cost is then paid upfront by the compiler. What's stopping a C programmer from hand-coding template instantiations (via macro or otherwise)?
I kinda want this on a mug or something.
Most C++ code I see has few vtables, and what vtables exist are mostly removed by the compiler. Java-style inheritance hierarchies are not idiomatic in C++. The code gen for C++ looks a lot like hyper-optimized C code, but without having to write hyper-optimized code. C++ naturally provides much more information about intent to the compiler than C does, and modern compilers are excellent at using that information to provide nearly optimal code gen.
FWIW I feel like this is a fairly recent (good!) development. Up through TR/TR1 I think at least half the C++ code I saw was pretty heavy on the "Java envy" and not at all concerned about the cost of dynamic dispatch or memory allocation. Avoiding vtables was derided as part of "C with classes" - today that usually refers more to templates and exceptions but STL implementations were not mature enough and too much code not exception-safe for those to be universally viable back then. Something I heard more than once was that if you had a destructor it should always be virtual just in case someone wanted to subclass it later.
Naturally we have to ignore that wxWidgets, Gtkmm, MFC, ATL, Qt, COM, DirectX, IO Kit, DriverKit, Skia are still around.
Being around long enough, the meme writing Java in C++ just rubs me the wrong way for something that was already common several years before Gosling even thought of Oak.
As if C++, alongside Smalltalk, and all those enterprise object modelling methodologies and books, weren't to blame for the widespread of that way of programming.
When Java came into the scene, those C++ and Smalltalk developers (and enterprise architects) migrated to it, and kept doing what were already considered "best practices" by then.
I mean, as much of a Qt user I am, that's definitely the case. All the libs you listed are still around, but no one writes new libraries in that style (sometimes at a performance cost, e.g. using a ton of std:: function instead of virtuals)
https://microsoft.github.io/microsoft-ui-xaml/
https://developer.apple.com/documentation/driverkit
https://www.khronos.org/registry/SYCL/
https://developer.nvidia.com/optix
https://docs.unrealengine.com/en-US/ProgrammingAndScripting/...
I could keep adding a couple more, but I think you got the point by now.