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

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

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.

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.

> hacks like conventionally placing the next/prev pointer in structs

This is not a hack, it is the way it should be in C.

Except that that's a linked list and not an array.

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.

Great, so now we're writing our own memory allocator?

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

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.

Except that more efficient solutions can be implemented much more practically? Solutions that you'd need to bend over backwards for in C?

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.

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.

> 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++.