Yes, but... even if you know that it is APL inspired, that does not change the fact that this is not how you want to write C.

The C pre-processor is probably one of the most abused pieces of the C toolchain and I've had to clean up more than once after a 'clever' programmer left the premises and their colleagues had no idea of what they were looking at. Just don't. Keep it simple, and comment your intent, not what the code does. Use descriptive names. Avoid globally scoped data and functions with side effects.

That doesn't look smart and it won't make you look smart, but it is smart because the stuff you build will be reliable, predictable and maintainable.

▲

piaste 2 days ago | parent [-]

Layman question: say you have a C codebase with a bunch of preprocessor macros and you want to get rid of a particular one that's too clever, and assume no other macros depend on it.

Is it possible to command the preprocessor to take the source files as input and print them out with that one particular macro expanded and no other changes?

Intuitively, it sounds like it should be possible, and then you'd end up with a code base with a bunch of repetition but one fewer too-clever abstraction - and refactoring to deal with repetition (if necessary!) is a far more approachable and well-understood problem.

(Kind of like how some fancy compiles-to-javascript languages have a literal 'mytool --escape' command that will turn the entire code base into a plain, non-minified javascript in case you ever want to stop using them.)

▲

jacquesm 2 days ago | parent [-]

That's a great question.

I found this on SO:

https://stackoverflow.com/questions/59553295/selective-macro...

Maybe that would work for your use case?

What I like about your question is that I always assumed the answer was a hard 'no' but that appears not to be the case.

	▲	piaste a day ago \| parent [-]
		It was a theoretical question. It's not the first time I hear the complaint '$previous_dev left a bunch of unmaintainable macro tricks in a C codebase' and I thought, since those macros get expanded as part of the compilation process, surely it should be possible to intercept and capture the expanded version? Even if a whitelist is not available (the SO question involves a particular C++ preprocessor and may not apply to others), a hacky approach might be to comment out all the #defines in the codebase, uncomment the ones you want to get rid of, and then run the full preprocessor task on it. Ugly but probably doable for a one-time refactoring.