Hacker News Reader

Comment by kaba0 | Hacker News Reader

Though C macros are so bad they give the whole term a bad name. You might as well write a sed script for “macro expansion” instead of what the preprocessor does.

View on HN

I think the case against the C preprocessor is overblown. What's the worst problem C macros have caused you? I've been programming C for 27 years and I can't really think of them causing any bugs in my programs. The worst thing for me is that #defines don't show up in the debug info.

C programmers tend to reach for the preprocessor in cases where other tools would have been more appropriate. In particular, #ifdef. If you haven't experienced this then maybe you've worked with people that have uncommonly good taste.

I agree there's nothing particularly terrible about the preprocessor as such, if used tastefully. Especially if you compare it to other macro engines like maybe TeX, CPP strikes me as quite simple and clean.

Even newer languages like Haskell choose to adopt it after all.

Good point about #ifdef. I'm not sure what other tools are more appropriate though. I went through a phase of moving target specific code into separate files instead of using #ifdef. But that makes the build system more complex and makes it harder to eyeball the difference between two targets' implementation of the same function. This is just an intrinsically complex problem and not one I blame the preprocessor for. As always, aiming for minimum total complexity is the goal. #ifdef is a useful tool in that persuit.

That said, I'd be interested to hear about other solutions that are better. I guess Zig's comptime is a candidate, but I see that as only a superficial improvement (not a criticism - I can't think of anything it could do better).

I agree, #ifdef is sometimes the best tool for the job. I didn't mean that it's always wrong, but it does tend to be overused in my experience. For instance, hardcoding assumptions about the target platform when a dynamic lookup could have been used instead. E.g. compare old skool hardcoded addresses in Linux drivers to modern devicetrees.

I don’t think Zig’s comptime is a superficial improvement, especially not compared to C “macros”. They are such a simple, single concept yet replace C++’s templates and const functions.

But a macro system without understanding the AST is just shitty.

Except I do not think you could (not easily, anyway), the C macro processor is a rather sophisticated piece of code.

Is it really though? I feel like I could implement a C macro preprocessor in Python in like two or three days.

People usually overestimate their capabilities when it comes to such things. In this case I think you are underestimating yourself, I do not see how anyone can write something as bad as the C preprocessor if they had 2-3 days to work with.

Writing a conforming C preprocessor is in fact quite hard. The spec is very hairy.

Reply on news.ycombinator.com