Is a preprocessor needed for a viable language?

How useful is the C++ preprocessor, really? Even in C#, it still has some functionality, but I've been thinking of ditching its use altogether for a hypothetical future language. I guess that there are some languages like Java that surviv开发者_StackOverflow中文版e without such a thing. Is a language without a preprocessing step competitive and viable? What steps do programs written in languages without a preprocessor take to emulate it's functionality, e.g. different code for debug and release code, and how do these compare to #ifdef DEBUG?

In fact, most languages deal very well without a preprocessor. I'd move on to say that the necessity of using preprocessor with C/C++ roots in their lack of several parts of functionality.

For example:

• Most languages don't need header files and include guards, because they have the notion of a "module".
• Conditional compilation can be easily obtained through static ifs or an analogous mechanism.
• Code repetition can almost always be reduced in more clear ways than what you can achieve with the preprocessor: using templates/generics, a reflection system, etc, etc.

So my conclusion is: for most "features" you can get with preprocessor and metaprogramming, a more clear alternative exists which is safer and more convenient to use.

The D programming language, as a compiled low-level language, is a nice example on "how to provide most features usually done via preprocessor, without actually preprocessing" - includes all I've mentioned, plus string mixins and template mixins, and probably some other clever solutions to problems usually solved with preprocessing in C/C++.

I would say no, macros are not needed for a language to be viable and competitive.

That doesn't mean macros are not needed in some languages.

If you need macros it's probably because there is a deficiency in your language. (Or because you're trying to be compatible with some other deficient language, like C++ is with C. :)). Make the language "good enough" and you will need macros so rarely that the language can do without them.

(Of course, it depends what your language's goals are what "good enough" actually means, and whether or not macros are a good way to achieve certain things or just a band-aid for missing concepts/features.)

Even in a "good enough" language, there may still be the odd time where you wish macros were there. Maybe they would still be worth having. Maybe not. Depends on what they bring to the language and what problems they introduce in terms of complexity (to the compiler/runtime and to the programmer). But that is true of any language feature. You wouldn't design a language with the aim to "have every single feature" so you have to pick & choose based on the trade-offs and benefits.

e.g. Templates are a fantastically powerful feature in C++, and something I find I miss occasionally in C#, but should C# have them? Should every language have the feature? Perhaps not, given the complexity they would bring with them (and the fact you can usually use C++/CLI for that kind of work).

BTW, I'm not saying "any good language doesn't have macros"; I'm just saying a good language doesn't need them. And FWIW, it used to irritate me that Java didn't have them, but that was probably because Java was lacking in certain areas and not because macros are essential.

It is very useful, however should be used with care.

Few examples where you need it.

1. Currently there is no other standard way to handle #include properly other then processor as it a part of standard. Also you need define to have include guard. But this is very C++ specific issue that does not exist in other languages.
2. Processor is very useful for conditional compilations when you need to configure your system to work with different API's, different OS's different toolkit, it is the only way to go (unless you want to create an abstract interfaces and then make conditional compilation on build system level).

3. With current C++ standard (2003) without variadic templates it makes life much easier in certain situations. For example, when you need to create a bunch of classes like:

   template<typename R>
   class function<R()> { ... }
   template<typename R,typename T1>
   class function<R(T1)> { ... }
   template<typename R,typename T1,typename T2>
   class function<R(T1,T2)> { ... }
   ...
   

   It is almost impossible to do it properly without processor in current C++ standard. (in C++0x there is variadic templates that make it much easier).

   In fact great tools like boost::function, boost::signal, boost::bind require quite complicated templates handling to make this stuff work with current compilers.

4. Sometimes templates provide very nice structures that are impossible without preprocessor, for example:

   assert(ptr!=0);
   

   That prints aborts the program printing:

   Assertion failed in foo.cpp, line 134 "ptr!=0"

   And of course it is really useful for unit testing:

   TEST(3.14159 <=pi && pi < 3.141599);
   

   That prints aborts the program printing:

   Test failed in foo.cpp, line 134 "3.14159 <=pi && pi < 3.141599"

5. Logging. Usually logging is something much easier to implement with macros. Why?

   You need either to write:

   if(should_log(info))
      log(info) << "this is the message in file foo.cpp, line 10, foo::doit()" << "Value is " << x;
   

   or simpler:

   LOG_INFO() << "Value is " << x;
   

   Which includes already: file, line number, function name and condition. Very valuable.

   In fact boost::log apache logging use such things.

Yes... Preprocessor sometimes is evil, but it too many cases it is extremely useful, so use it smartly and with care and it is fine.

However if you implement with it:

• Macros instead if inline function.
• Unreadable and unclear macros to "reduce the code"
• constants

You are do it wrong.

Bottom line

As every tool it can be abused (and beleive me I had seen very crazy preprocessor abuse it real code) but today it is very useful thing.

You do not need preprocessing step to implement conditional compilation. You do not really need macros (one can live without stringize and token-paste operators, and even these could be done without PP). #includes are a very special kind of nightmare, which models the reference invocation all wrong.

What else is so important?

It would depend upon what you consider 'viable', but In C++, a lot of the necessity for/desirability of using macros has been obviated by features such as templates, inlining and namespaces. The only reason I find myself using macros in C++ is for integration with C (#ifdef __cplusplus in headers and processing definitions). With other languages, this is unnecessary with tools like JNI or SWIG to generate C headers/libraries.

Rather than use macros to control 'debug' and 'nodebug' builds, it would make more sense for the compiler to include a debug compile option to include/enable the necessary features.

Several languages just work without macros; if you're looking for a C-like language to compare with, I suggest D http://www.digitalmars.com/d/2.0/comparison.html