Hacker News Reader

Comment by bachmeier | Hacker News Reader

On the topic of the presentation, I'd be happy to have a way to kill the preprocessor. Not that I expect that to happen. Reading C code is like reading literature that only makes sense if you know eight languages, four of which are known to fewer than 100 people.

View on HN

I've often wondered why C++ hasn't deprecated the preprocessor yet. D has hygienic replacements for all the things the C preprocessor does (except the nutburger stuff), and we're quite happy with that.

My guess is that they won't because it would dramatically decrease the subset of code that is both valid C and valid C++ in many environments. As you are no doubt aware, most C -- not all, and not with perfectly preserved semantics -- is valid C++ in practice. I think the C committee would have to do something first. But I'm only an outside observer.

C has already added things not in C++, like _Generic.

C would be a lot harder to write without the preprocessor. I have only really had one truly awful experience with the preprocessor in the last 15 years and it was when reading OpenSSL's code. Even then, I didn't have too much trouble to grok it with just Vim.

I discovered my C code was a lot better when I backed out all the clever metaprogramming preprocesser usage. C could be easily extended with:

1. modules

2. manifest constants

3. conditional compilation

and the preprocessor can be deprecated.

This kind of insight was a driving force in the design of https://odin-lang.org/

For me, it is hard to imagine to program in C without preprocessor metaprogramming. Obviously, it would be better if generic types and metaprogramming were available directly in the language. Alternative is either copying code and adapting it manually, or depending on generic code with many void * arguments.

If one really needs metaprogramming, it's time to move to a more powerful language. There are plenty of them.

> If one really needs metaprogramming, it's time to move to a more powerful language.

It's wholly wrong to try to frame this as "more powerful", specially considering the fact that C already supports generic selection.

https://en.cppreference.com/w/c/language/generic

> There are plenty of them.

There really isn't, at least in the application domains where C dominates, such as embedder programming.

You'd be hard pressed to find any producrion-level tool chain for embedded development which supports anything other than C or even C++, and any decision to pick up even C++ over C for embedded development requires a lot of soul searching.

Nah, the C preprocessor is a disgusting hack. I really don’t understand why they didn’t opt for a more logical, AST-based macro system when the base language has such bad expressivity in itself.

This differs from web applications how? (not that you said it did, but the implication seems to be that C is an exception in software development in this regard)

I'm not a webapp dev, but C/C++ always felt unique via the preprocessor functionality that essentially does text substitutions on source code before handing off to the compiler.

Actual flags are useful, e.g. -codegenfoo -linkflagbar, but I hate digging through a maze of -DFLIPOPTION1 and -DUSERSUPPLIEDTEXT="hahaha" to unscramble what code the compiler actually sees, and what went wrong because of the various user supplied strings (i.e. #define overwrites).

If other languages also have this, well ugh sorry. I have grown to despise it.

Why eight?

Reply on news.ycombinator.com