“C is quirky, flawed, and an enormous success”

Re:“C is quirky, flawed, and an enormous success” – Dennis R... by binjooou on Sunday July 09, 2023 @09:00AM (#36654132)

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);

[ Parent | on HN ]

Re:“C is quirky, flawed, and an enormous success” – Dennis R... by dermesser on Sunday July 09, 2023 @09:29AM (#36654305)

Six arguments - seriously? Avoiding that is the point of generic programming, and probably more efficient there too

[ Parent | on HN ]

Re:“C is quirky, flawed, and an enormous success” – Dennis R... by kaba0 on Sunday July 09, 2023 @10:08AM (#36654557)

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.

[ Parent | on HN ]

Re:“C is quirky, flawed, and an enormous success” – Dennis R... by variadix on Sunday July 09, 2023 @12:42PM (#36656015)

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.

[ Parent | on HN ]