​I hear you and partially agree.  But I would point out that my experience in 40+ years of professional "coding" the programs that have "lasted" the longest and matured the most over time, were all written in a language that had some sort of preprocessor.​  Using a preprocessor is not a bad thing, it's the miss use that is the problem and leaving it out I think weakens the language.

IIRC: Brian made this same point in the "Why Pascal is not my Favorite Programming Language."

I think your point of over use, is valid (like symlinks in the file system - my curmudgeonly beef) - just because we >>have<< a feature does not make it the best way to do something.   I like to think of this sort of choice as "good taste" --  simple and elegant.    ifdef's are a real solution to a problem.   But like you, I >>hate<< seeing them all over the place and they certainly can muck up the code.

BTW:  I much prefer a local_func.c which sucks in unix_bindings.c, vms_bindings.c, winders_bindings.c or the like with ifdefs and alls the configuration control needed in >>one<< place;  and then all of the rest of the code try to be a pure as possible as you describe.

FWIW: One of the best I ever saw was the old FORTRAN SPICE 2G6 of Ellis Cohen and Tom Quarles.   That program runs everywhere (still does).   Ellis and Tom used m4 to preprocess it, IIRC and keeps the localization in a very controlled space.   If you even looked at it, Ellis does some really imaginative coding (compiling the internal loop in a data block and jump to it), it all portable and actually very easy to understand.  For one thing the comments are there and very, clear.

But Ellis has great style and have mopped up after a number of other of the UCB greats in those days, I'd much rather deal with Ellis's and TQ's code base then some of my other peeps.

Anyway - I agree - ifdef >>is<< miss used in way too much code, but I think part of that is so many programmers never had a real software engineering course ( a thought I will follow up in another thread).

Clem