Re:Why is Rust slightly slower than C?
by otabdeveloper2 on Thursday September 12, 2019 @01:50AM
(#20948419)
> given the right subset of language chosen
Yes, if by that you mean "idiomatic C++ as C++ programmers write it".
It's the inexperienced "C/C++" (no such thing, BTW) that are 'choosing subsets', and doing it wrong 90% of the time.
Re:Why is Rust slightly slower than C?
by monocasa on Thursday September 12, 2019 @04:06PM
(#20955848)
> It's the inexperienced "C/C++" (no such thing, BTW) that are 'choosing subsets'
That's blatantly not true. Strousup himself contributed to the joint strike fighter C++ coding standard which has things like "Allocation/deallocation from/to the free store (heap) shall not occur after initialization." which means that the STL is off the table for example.
Beyond that, there's pieces like RTTI/dynamic_cast that should be avoided for a lot of reasons, perf being one of them.
Most of the STL does no allocation. The containers allocate only at known places, permitted during initialization. They also know how to allocate from provided bespoke stores, which are permitted, in JSF code, even after initialization is done.
So, no, the STL is very much on the table, as in any competently constructed work product.
What the parent is saying is essentially right. C++'s compile time polymorphism and lamdas can allow faster than C given the right subset of language chosen. For instance std::sort regularly outperforms qsort(3).