4 ms·

> You don't have to use an inefficient solution. You can always roll your own optimized solution or use a library That’s not true. You for example can’t write

• xyzzy_plugh 3y ago
  You're talking about something that isn't related to efficiency. Copy and pasting, macros, generating code -- none of these preclude producing an efficient solution. There is nothing in C++ that is inherently more efficient than C.
  • dermesser 3y ago
    Except that more efficient solutions can be implemented much more practically? Solutions that you'd need to bend over backwards for in C?
    • xyzzy_plugh 3y ago
      What does that have to do with efficiency? We don't appear to be debating language ergonomics, but the notion that C is somehow inferior to C++ when it comes to performance.
  • humanrebar 3y ago
    C++ has a lot of compile time programming features that C cannot do practically. There are sometimes alternatives to those mechanisms in C, but they rely on mangling, macros, non-portable tricks, and so on. On the topic of performance, the best counterargument to C++ from a C perspective would be that hand rolled code generation isn't all that bad in practice. It's just language theorists don't like that approach aesthetically.
• coliveira 3y ago
  > hacks like conventionally placing the next/prev pointer in structs This is not a hack, it is the way it should be in C.
  • dermesser 3y ago
    Except that that's a linked list and not an array.
    • flohofwoe 3y ago
      You can store your 'list items' in an array and still link to random items in the array - although an index instead of a pointer would make more sense in that case, but what else is an index than a pointer with fewer bits ;) The main advantage being that you don't need to alloc/free individual items.
      • dermesser 3y ago
        Great, so now we're writing our own memory allocator?
        • flohofwoe 3y ago
          If you want to call about 10 lines of trivial code a 'memory allocator', then yup, we're totally going to write our own 'memory allocator' ;)
• binjooou 3y ago
  Generic things are rarely efficient, the most optimal code tends to be specialized and tailored to specific hardware and/or the kind of data its operating on. std::vector (which is a really inefficient way of doing dynamic arrays btw) can be cleanly implemented with macros (see stb stretchy buf) or by splitting the element data from the housekeeping data: int append(void *arr, size_t elemsize, size_t *capacity, size_t *size, const void *items_to_add, size_t num_items_to_add);
  • dermesser 3y ago
    Six arguments - seriously? Avoiding that is the point of generic programming, and probably more efficient there too
  • kaba0 3y ago
    How is std::vector is inefficient? Especially that that macro-hack from stretchy buf seems to do it in an even more naive way. Splitting the element data is a different implementation with very different performance characteristics - it’s quite a bad thing if I have to resort to that due to a language inefficiency, especially in case of a language that is supposedly close to the hardware.
    • variadix 3y ago
      There are various constraints on std::vector because of language in the standard which makes concessions for generic use that might not apply to your application. Small vector optimizations aren’t possible in std::vector, also some operations that could be done in-place can’t be. You also give up control of some meta-parameters and allocation strategies that may be more efficient for your use case.
• pkkm 3y ago
  > I very much question that “you don’t write C as C++ part”, if anything you don’t write C++ as C as that would be inefficient. Yeah, I was thinking about your string example when I wrote that. For high performance numerical code, I can see the advantages in using C++.