Comment by 0c3ca83
19 hours ago
Doing non-trivial preprocessing is a mistake. You get slow compilation, hard to debug code, opaque and fragile code, and incredible complexity. If you want metaprogramming, you're better off with C++ it you need C header compatibility, or zig if you don't.
Otherwise, it's probably a good idea to pretend that the only preprocessing directive is #include. With constexpr, even #define is obsolescent.
Doing non-trivial anything you slow down compilation, make debugging harder and increase fragility and complexity. Sometimes that's a mistake, sometimes not.
Getting rid of something because someone sometimes abuses it, is short-sighted.
You don't need to get rid of it to leave it unused. Macro wizardry leads to poor code.
Yes and no. If you want to make something like a generic dynamic array, you can do it with type erasure (`void*`), but then your code is no longer typesafe. I would find that more fragile. The preprocessor allows you to add constructs that make it behave like any other modern language.
As an aside, clangd can dereference a macro in place to make debugging easy.
And for generic data structures one can also a very thin layer of macros around type-erased implementations.
You're usually better off just using realloc, or an abort-on-oom wraper of it, in my experience.
> slow compilation, hard to debug code, opaque and fragile code, and incredible complexity
Most people describe C++ in those terms.
Exactly. So if you're willing to accept that downside, C++ does a better job of letting you express that kind of cleverness.
I am not sure. I agree one should minimize macros in C, but for some things a small macro layer still beats the complexity of C++ and is not inferior in my opinion.
6 replies →