Oipo edited a comment on pull request #259: URL: https://github.com/apache/celix/pull/259#issuecomment-660300018
> is there any metric data regarding performance, code size etc - compared C and "new" C++? The discussions surrounding language X vs language Y are always very difficult, because are you really comparing apples to apples? In terms of C++ vs C performance, there are many huge differences in tiny places, but can be explained easily if you dive into it. Generally speaking, for each run-time metric you think of, what you can achieve in C, you can achieve in C++ and vice-versa. For example, C++'s `std::sort` is faster than C's `qsort`. Not because C++ is faster, but because the underlying algorithms are different. GCC's`std::sort` uses Musser's introsort where `qsort` uses quicksort (though I haven't verified that one for GCC specifically). Hence, C++ seemingly has a speed advantage here, which would disappear if the same algorithms were used. But really, for each engineering problem you solve with the same fundamental concepts in C, you can get an exact assembly output copy with C++. Though that would often mean not using exceptions, which would preclude many usages of the std library. But even for those situations, people have made std-like [libraries](https://github.com/electronicarts/EASTL) to give many of the same benefits, without using exceptions. Benchmarking C vs C++ most certainly has been done. See the [Benchmarking Game](https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/cpp.html), this [C++17 specific paper](https://stellar.cct.lsu.edu/pubs/closing_perf_gap_isc_2016.pdf) or one of the [many](https://www.r-bloggers.com/the-need-for-speed-part-2-c-vs-fortran-vs-c/), [many](https://deathbytape.com/articles/2015/01/30/c-vs-c-performance.html) other publicly available resources. In fact, [here](https://www.viva64.com/en/b/0733/) is one comparing rust with C++, which comes to pretty much the same conclusion as I have: the same class of languages perform the same. Rust, C and C++ are all systems-class languages where you manage your own memory, giving very comparable performance results. Note that you'll find resources such as [this 2003 paper](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12.6227&rep=rep1&type=pdf) on the decrease of performance in C++, but in the 17 years since, C++ and the compilers for C++ have advanced a lot. Take the constexpr feature of C++17 for example, [Jason Turner's CppCon presentation](https://www.youtube.com/watch?v=PJwd4JLYJJY) shows that the compiler can move a lot of computation from run-time to compile-time. I do not know of any C equivalent, other than the pre-processor which is a partial equivalence at best. The questions surrounding run-time performance are therefore (in my not so humble opinion) the least important surrounding the decision to move away from C. The right question should be: Which requirements do we have for celix and which language best fulfills those? Or alternatively, which requirements do we have for celix and does C still fulfill these needs? I had already written a large reply on trying to answer that question, but I don't think this is the right place to discuss it. I will say though that it is my strong personal belief that using C for celix has introduced a lot of difficulty in implementing things bug-free and it is noticeable by all the bugs we're continuously creating when adding new features. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
