To be charitable, I'm gonna interpret this as hyperbole. If you meant this as its written, it'd be an immensly ignorant statement.
Almost by definition, there CAN always be a faster implementation in C++ but there are also more ways to shoot yourself in the foot (or as they saying with C++ goes, shoot your leg off).
I think this is pretty much exactly right with the caveat that "fast implementations" is probably "the overwhelming majority of implementations". `libpthread` on GNU has been doing this since smart phones were quite the novelty. I'm sure it exists, but I'm having a hard time imagining who wrote a C++11 compliant standard library and didn't do this optimization.
C++ has done a pretty good job of maintaining the ideal that "you don't pay for what you don't use". Your C++ is too slow? Think carefully about which features you're using.
If you choose features appropriately (given that speed is your top concern), and you still find that another language is faster, I'd be quite surprised.
It's futile battle though to achieve both performance and safety in C++: as an example, safety requires avoiding moves, using reference counting, while achieving performance means avoiding copies and passing occasional references around, among other things. That's why advertising C++ solution as fast does not work well with "but C++ can be safe too!".
In modern C++ it is very much possible to write fast and safe code, but the tradeoff is now put into the amount of stuff the developer needs to know to be productive (Which in my experience isn't as bad as people like to go on about on here/reddit, even if it still pretty shoddy)
Not quite to the degree that C++ does, but it's pretty good. There are several places in the standard that specifically allow for making a dynamism/performance tradeoff.
C++ is designed to be as fast as C even when you use the advanced features like templates, at the expense of compilation speed, so I think it must be equally suitable.
reply