| ▲ | afdbcreid 5 hours ago | |
I explicitly acknowledged that: > The only candidate is using virtualization and void* pointers instead of monomorphized generics which some C code does for the lack of better options, but that's not a problem in Rust as well. But in fact, if speed is a concern to you, even in C you will use "templated" sorting (via macros or code generation). | ||
| ▲ | 20k 5 hours ago | parent | next [-] | |
The problem is that the implementation burden with C is so high, that people tend not to do it even in relatively performance constrained situations | ||
| ▲ | loeg 3 hours ago | parent | prev | next [-] | |
> in practice no one really does with C because macros [and codegen] suck too much | ||
| ▲ | fluffybucktsnek 4 hours ago | parent | prev [-] | |
Neither codegen nor macros (they are a part of the preprocessor) are really a part of C. For the latter, the lack of integration becomes more noticeable if you try writing a macro in which the compare param can accept a function identifier. As the preprocessor doesn't have the knowledge of the contents of the referred function, it can't inline it. In C++ and Rust, their compilers do, so they can. A codegen tool could overcome this, but you could also make a codegen tool to write Zig/D/C#/Swift in C, or any other language for that matter :). By this point, one could say you are programming in a superset of C, not strict C. | ||