Performance? Not really no. I believe C is slightly faster with Rust and C++ competing for second place. The benefit is safer code as Rust is built with performance and safety in mind. It highlights what potential errors can be found where making human error way less common. Instead of potential null errors types are wrapped in an option enumerator which ensures you know there can be a lack of a value. Expections are also enumerators done similarly with a result object so you know which functions may fail. Instead of using memory and potentially forgetting to free it we have the ownership system.
The use of basic classes can very quickly become a performance issue because of data locality issues, confusing the branch predictor, and generally using instructions where C wouldn’t need to.
They’re honestly insignificant compared to the value you get in return, especially with the better typing and application design, but they’re there.
If you stick to the builtin classes, no capturing lambdas, don’t use too many generics, and use const often enough, you should be able to produce code that’s as fast as C. At that point you may as well use C, though, especially because one mistake with semantics and you’re back to hitting C++ related performance issues anyway.
That’s just plainly false. A std::sort() for examples beats a qsort() easily. C just doesn’t have the tools to handle that kind of thing without a lot of manual code duplication.
The reason for not using C++ is simply that it’s a huge monster of a language, that makes it difficult to find common ground for a programming style. In C that is much easier as you have much less features to worry about. It is more verbose and error prone, but also more predictable and easier to review, as the code you see is what you get in the binary. In C++ can have a mountain of stuff hidden behind operator overloading, exceptions and other stuff, which makes it very difficult to reason about.
Aside from that I think C is more performant than C++ (indeed when you use the bells and whistles that C++ offers), you are comparing the libraries with each other.
The fact that the implementation of one random std::Sort is faster than the implementation of qsort() is comparing libraries, not the languages. You are comparing the algorithm of the Rust Sort with quicksort (which is obviously the qsort you are referring to.
I am certain there are sort implementations in C which outperform Rust.
Having said that, I immensely enjoy Rust because it forces me to think about the error handling and it does not give me the quirks of C/C++ (index out of bounds, memory corruption).
In this video, we’ll do a deep dive on what C++ Polymorphism is, what “virtual” does under the hood, and ultimately why it is SUCH a performance hit compared to languages like C and Rust.
Performance? Not really no. I believe C is slightly faster with Rust and C++ competing for second place. The benefit is safer code as Rust is built with performance and safety in mind. It highlights what potential errors can be found where making human error way less common. Instead of potential null errors types are wrapped in an option enumerator which ensures you know there can be a lack of a value. Expections are also enumerators done similarly with a result object so you know which functions may fail. Instead of using memory and potentially forgetting to free it we have the ownership system.
How is C faster than C++? Unless you use virtual functions, it’s as performant as C. And you definitely wouldn’t use virtual functions in a kernel.
The use of basic classes can very quickly become a performance issue because of data locality issues, confusing the branch predictor, and generally using instructions where C wouldn’t need to.
They’re honestly insignificant compared to the value you get in return, especially with the better typing and application design, but they’re there.
If you stick to the builtin classes, no capturing lambdas, don’t use too many generics, and use
constoften enough, you should be able to produce code that’s as fast as C. At that point you may as well use C, though, especially because one mistake with semantics and you’re back to hitting C++ related performance issues anyway.C++ is only as fast as C if you use only the parts of C++ that are identical to C. In other words, C is faster than C++
That’s just plainly false. A
std::sort()for examples beats aqsort()easily. C just doesn’t have the tools to handle that kind of thing without a lot of manual code duplication.The reason for not using C++ is simply that it’s a huge monster of a language, that makes it difficult to find common ground for a programming style. In C that is much easier as you have much less features to worry about. It is more verbose and error prone, but also more predictable and easier to review, as the code you see is what you get in the binary. In C++ can have a mountain of stuff hidden behind operator overloading, exceptions and other stuff, which makes it very difficult to reason about.
Aside from that I think C is more performant than C++ (indeed when you use the bells and whistles that C++ offers), you are comparing the libraries with each other.
The fact that the implementation of one random
std::Sortis faster than the implementation ofqsort()is comparing libraries, not the languages. You are comparing the algorithm of the Rust Sort with quicksort (which is obviously theqsortyou are referring to.I am certain there are sort implementations in C which outperform Rust.
Having said that, I immensely enjoy Rust because it forces me to think about the error handling and it does not give me the quirks of C/C++ (index out of bounds, memory corruption).
You can use compile time polymorphism in C++ without any runtime performance cost.
Unfortunately, that’s not true
The description says:
This is not about compile-time polymorphism.