4 ms·

> I am pretty sure C++ effectively passed C a while ago given good compilers Citation? Every benchmark I've ever seen still has C coming out on top: https://be

• pjmlp 7y ago
  It is always a matter how good are those benchmarks written. For example, good luck achieving in C what is possible to do in C++ with constexpr at compile time, and will require an additional runtime cost during the benchmark execution. Or sorting data via qsort() versus STL sorting algoritms with templates, which in C always require the runtime cost of an additional indirect call. Or now with C++20 contracts, validation of pre-conditions, which with C are only possible at runtime, while C++ can already make use of the information if available at compile time. C++Now 2019: Odin Holmes “Hey C, This Is What Performance Looks like" https://www.youtube.com/watch?v=CNw6Cz8Cb68 https://www.youtube.com/watch?v=CNw6Cz8Cb68
  • flukus 7y ago
    > It is always a matter how good are those benchmarks written. I agree it's not perfect, but I'm yet to see a single set of benchmarks show that "C++ effectively passed C a while ago" and yet I see it claimed somewhat frequently around here. Generally the games I see around benchmarks go the other way though, with people effectively writing C in the comparison language and not idiomatic code. > For example, good luck achieving in C what is possible to do in C++ with constexpr at compile time The only thing constexpr solves AFAIK is doing it all in c++, generating compile time constants is hardly magic and it's been solvable with anything from a shell script to something more complicated forever. > Or sorting data via qsort() versus STL sorting algoritms with templates, which in C always require the runtime cost of an additional indirect call. It's not as ergonomic, but things like this are also doable with _Generic in modern C.
    • clappski 7y ago
      constexpr is much more powerful than just generating constants (although that is one of the bigger use cases). One of the things I like is how it simplifies doing static dispatch on template types, essentially using SFINAE under the hood but in a much simpler way to read: if constexpr ( std::is_same_v<T, int> ) { ... } Vs template <typename T, typename std::enable_if_t<...>* = 0> void fn( T t ) { } Being able to generate constants using the language itself is super powerful as well (the below is a bit contrived, as std::string_view is constexpr and obsoletes this pattern): static constexpr std::array<char[], SIZE> strs = { ... }; static constexpr std::array<size_t, SIZE> str_lens = calc( strs ); // Where calc() loops over the array and calls std::strlen, all at compile time
    • pjmlp 7y ago
      Then look at Eigen vs alternative C libraries for example. Constexpr allows for compile time code execution, introduced in C++11 and extended with each C++ revision, C++20 version even allows for partial STL use. There is plenty of stuff one can do with it, when coupled with template metaprogramming, it is basically C++'s version of Lisp macros, although a bit clusmy. Generating constants is just the tip of the iceberg. Using shell scripts is language agnostic solution. _Generic is very constrained, try to implement std::sort() for any kind of datastructure with it, not only basic numerical types.
    • gdy 7y ago
      "it's been solvable with anything from a shell script to something more complicated forever" By this logic C as good as any language as long as you can compile that language to C.
      • flukus 7y ago
        The logic is more "why add complicated features to a language when there are existing ways to have the same functionality". C++ is already over complicated, the last thing it needs are more features. This effort is also being replicated across several languages with all there own syntax and warts. Generating source code via a script or template library is much more compositional.
  • jstimpfle 7y ago
    > qsort() versus STL sorting algoritms with templates This is one of the most popular examples for superiority of template instantiation. Yet when I measured the speedup on integer arrays (where arguably you can expect the largest speedup) it was less than 2x. Now considering also the tradeoffs that come with using C++ (larger compile times, larger binaries), and the fact that sorting is rarely a bottleneck, I'm not so sure anymore that std::sort is generally superior.
    • pjmlp 7y ago
      That is a popular example, because it is a simple way to describe the difference between templates versus bare bones C coding. And in some scenarios even a little 2x speedup does impact With template specializations that speedup can be increased even further and since compiler does see template bodies, there are even more opportunities for the optimizer to do its work. C++ can be used in something like a Commodore 64 just fine, in fact with smaller binaries thanks to constexpr all things. CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17” https://www.youtube.com/watch?v=zBkNBP00wJE https://www.youtube.com/watch?v=zBkNBP00wJE
    • patrec 7y ago
      A decent C++ compiler will also inline the sorting for something like: constexpr size_t N = 3; void sort_N(std::array<int, N> a){ std::sort(std::begin(a), std::end(a)); } but I haven't checked if it does the same with qsort. But I agree with your larger point; I find the efficiency claims for C++ frequently overblown and the compile time burden substantial (OTOH it's still very hard, but slightly easier to write robust code in C++ compared to C).
    • flukus 7y ago
      2x is actually pretty significant consider the only difference is the way the comparer is called. Also consider how is easy it is to apply similar boosts in many scenarios with little mental overhead and it's a significant win for c++. C has _Generic though which can do the same, it seems a bit unfair to be comparing an old method kept for backward compatibility with C89 with whatever version of c++ and the compiler gained this advantage.