3 ms·

I hate how people group C with convos like this. Sure it has problems, but does not have any to the insanity that C++ can, let alone hiding it like C++ can. Th

• jandrewrogers 5y ago
  C++ is a massively bloated language. But it is also vastly more expressive and more safe than C, and also significantly faster at runtime. It just has a stupidly high barrier to entry.
  • anfilt 5y ago
    Making a language more expressive at risk of making bugs less obvious is not a good thing. The goal with expressive syntax is to make code easier to read/write, not deceive the developer. Also C++ does not have a faster runtime than C. C has hardly any run time requirements. Mainly just setting up the stack, compared to C++'s runtime requirements I don't see how anyone could claim the C++ runtime environment is faster. Anyways, my point is that C and C++ have diverged far enough these days bundling them together is not really productive nor accurate.
  • flohofwoe 5y ago
    C++ cannot be safer than C as long as it remains backward compatible, which would mean becoming a fundamentally different language. You can't fix a leaky pot by adding another leaky pot on top (err, or something...). Also "significantly faster at runtime" seems like a stretch. C++ doesn't have any fundamental features over C that would affect performance (for instance, it doesn't fix the pointer aliasing problem).
    • zabzonk 5y ago
      The poster child for C++ being faster than C is std::sort() vs qsort(). The latter requires a function pointer dereference for each call to the user-supplied ordering function - the former does not. There are many similar opportunities for C++ to be faster than C.
      • flohofwoe 5y ago
        The solution for C would be to "stamp out" a specialization of qsort() for a specific data structure either manually or with code generation. The C++ template system really isn't some "magic performance pixie dust", it just saves some typing ;) ...or alternatively, with global optimization (LTO/LTCG) there's actually a good chance that the comparision function calls of a C qsort() implementation can be "dissolved" via aggressive inlining as long as all required parts are visible to the compiler - that requires a lot of trust in the compiler though (on the other hand, C++'s "zero cost abstraction" philosophy requires the same level of trust).
        • zabzonk 5y ago
          Much of what you say is true, but I'm not sure that this is: > (on the other hand, C++'s "zero cost abstraction" philosophy requires the same level of trust). The C++ Standard _requires_ that a Standard Library implementation implements certain performance guarantees - I don't think the C Standard has such requirements. This means that certain implementations are effectively required - for instance that std::map is implemented (for better or worse) as a red-black tree.
          • gpderetta 5y ago
            To be clear, the standard mandates the complexity of most standard library functions. In no way it mandates zero copy abstraction (and it is not clear how one would even word that). Features are usually defined in such a way that zero cost abstractions are at least known to be possible though.