Preprocessors Are Not Evil

"Our language has X so we do not need a preprocessor." This is a very common statement in the JavaLanguage community and elsewhere. Even BjarneStroustrup gets into the act and tells us that we don't really need #define in CeePlusPlus because we have the ConstQualifier.

-- I doubt BjarneStroustrup said this as it isn't true. There are many uses for #define besides definition of simple constants. inline code, generics, conditional compilation, code generation to name but a few. NickKeighley

Apparently, he said it in Design And Evolution Of C++. Though it was apparently limited to C's preprocessor.

Like GoTos and MultipleInheritance, macro preprocessors bear onus for much of the evil in the world. Is this fair? Sure enough, people have gotten themselves in a lot of trouble with these things, but we will have to see whether banning them (which prevents even sensible use) is worthwhile. Judges in law often make the point that FreedomOfSpeech has no teeth if it is interpreted in such a way that all content must be suitable for the ears and eyes of a six year old. Likewise, we may find that systematically reducing our languages is no substitute for learning how to use the fire without getting burned by it.

See DesignByContract for an example of how a preprocessor makes the implementation of DBC painless and very powerful in C++. Compare it to the work that has to be done in Java to accomplish substantially less (EfficientContractsInJava). Note, that the answer is not "use C++." The answer is "add a preprocessor or at least DBC to your language." SmalltalkLanguage programmers live with the possibility of MetaClass programming without burning themselves over and over, so it can be done.

What you are saying here is that the various facilities offered by preprocessors are not evil: but I still contend the preprocessor itself is. Assuming by "preprocessor" we mean something which manipulates program text with only the shallowest understanding of its syntax and semantics.

CeeLanguage is like that. C macros are not hygenic, they do not respect the scoping rules of the language, they are prone to SideEffects, and so forth. The problems are well known and well documented.

This doesn't mean macros are bad. Certainly it's useful to be able to specify transformations that happen at compile time rather than runtime. We need hygenic macros that operate on parse trees rather than source text. We need literal constants, templates, inline functions. We need meta-object programming. We need stuff to be integrated deeply into the language, not slapped on as an afterthought. Sorry. Naive preprocessors are evil.

-- DaveHarris

But preprocessors let you shoehorn into the language things that the language itself just isn't designed to make easy. Most languages are so gung-ho on doing things just one way, a loosely coupled preprocessor is a godsend. So all the overcomplex CeePlusPlus trickery mentioned still doesn't kill the need for #define; the only languages that really don't need preprocessors are extension languages like PerlLanguage and ToolCommandLanguage that let you do eval. -- PeterMerel
It would be better if the language itself was designed to make it easy. What special magic does a preprocessor have, that it can do things a decently designed language cannot do itself? You are not going to convince me of anything by using examples from CeeLanguage, CeePlusPlus, JavaLanguage or FortranLanguage. -- DaveHarris

I'm just glad that I can do DesignByContract in CeePlusPlus using the preprocessor. I was not exactly glad, but I was somewhat satisfied that I was able to port a C++ class library of mine years ago to run under IntelCorporation CeeLanguage for an EmbeddedSystem using my own hand-coded VeeTable dispatching wrapped in macros.

So, to me, tools are never evil. Tool users? Well...However, I do agree wholeheartedly that it would be good if more languages supported precompilation transformations.

-- MichaelFeathers

I'll second that. I love the preprocessor, especially in CeePlusPlus. There are generally other solutions available, but if you weigh the expense you often find #define is lighter than the alternative. In many situations (conditional compilation, IncludeGuard, variadic functions) there just is no alternative. And when you have to do dirty stuff like Michael's vtable hack, #define is the only way to make the code look livable. Then again I'd say that MultipleInheritanceIsNotEvil either ... -- PeterMerel
Conditional compilation and variadic functions can both be implemented using templates, however.

You can write preprocessors for any language, there doesn't have to be a specific one bound to the language. The CeePreprocessor is powerful enough to allow a capable and tasteful user to accomplish many useful things, but also allows any user to blow off assorted metaphorical limbs (in this, cpp is in synch with much of CeeLanguage; a lot of what's happened with CeePlusPlus and AnsiCee reduces this risk by moving more things like constants and generic expansions from preprocessor idioms into the language proper).

If the cpp conventions weren't so bound up with C implementations, we might have adopted something different by now, but since it's there we tend to use it. I have a fairly complete implementation of C++ exceptions based on some simple macros (from the days before one could rely on all compilers to implement them, but still in use). In hindsight, were I doing it again, I would write a custom preprocessor (a PerlLanguage or AwkLanguage script, say) instead of the macros.

There's nothing at all stopping anyone from doing the same to implement DesignByContract in JavaLanguage -- you can even code the same solution given for C++, you just have to run the cpp phase explicitly in your build scripts. Of course, it would be better if the language itself supported the idiom in a more native way.

--JimPerry

However, using a preprocessor is socially acceptable in C++. If you used one in Java, you'd probably never live it down. Your tools probably wouldn't be kind to you, either.

For those wishing for macros without chaos, you might peruse DylanLanguage. The language itself features a structured macro facility, which advocates claim is quite powerful, and safe. (p.s. I use C++, and I like the DesignByContract assert macro.) -- AlanBaljeu?

Nobody has mentioned the big problem I have with preprocessors (perhaps nobody else finds it a problem?) which is that when something goes wrong the error will be reported in the transformed text, not in the original. This gets progressively more frustrating as the transformations get more complex, on a scale of 'typical #define use' at the simple end to 'imake' (or automake) at the other. -- DanBarlow

Of course, in the CeeLanguage program itself, errors show up in the output, not in the program. Given that the preprocessor is essentially a programming language that generates a C program, it couldn't really be any other way.

I definitely feel that #include is evil, and that it should have been buried a long time ago (and replaced by a language statement that imported a real interface file). This would tremendously speed up compilation, since one could have (gasp) pre-compiled interface files. I mean, things like PascalLanguage has had for about 20 years. Yes, I know about pre-compiled headers. They are non-standard and fragile against changes in the #include order. I really don't understand why this problem with C and C++ has not been fixed. -- StephanHouben

CategorySyntax CategoryCee