Why should one bother with preprocessor directives

Question

This question may seem rather basic, but coming from an engineering (non computer-science) background, I was unsure about what the snippets of '#'s were in some C++ code.

A quick search led me to the concise, well-explained cplusplus tutorial page on preprocessor directives.

But why bother with the concept of preprocessor directives at all? Is it not possible to write equivalent code that can assign values to constants, define subroutines/function/macros and handle errors?

I guess I ultimately want to know when it is good practice to use such preprocessor directives, and when it is not.

Answer 1

You use preprocessor directives when you need to do something outside of the scope of the actual application. For instance, you'll see preprocessing done to include or not include code based on the architecture the executable is being built for. For example:

#ifdef _WIN32 // _WIN32 is defined by Windows 32 compilers
#include <windows.h>
#else
#include <unistd.h>
#endif

Preprocessor directives are also used to guard includes so that classes/functions etc. are not defined more than once.

#ifndef MY_CLASS_6C1147A1_BE88_46d8_A713_64973C9A2DB7_H_
#define MY_CLASS_6C1147A1_BE88_46d8_A713_64973C9A2DB7_H_
    class MyClass {
    ....
    };
#endif

Another use is for embedding versioning inside of code and libraries.

In the Makefile you have something along the lines of:

-D MY_APP_VERSION=4.5.1

While in the code you have

cout << "My application name version: " << MY_APP_VERSION << endl;

Answer 2

It's a better-than-nothing substitute to get some reflection capabilities out of C++.

Very useful to generate variables and strings with the same names.

Answer 3

Preprocessing occurs before the code is compiled. It's appropriate in cases like the following

#ifdef WIN32
#include <something.h>
#elseif LINUX
#include <somethingelse.h>
#endif

Obviously including header files you want done at compilation time not runtime. We can't do this with variables.

On the other hand. With C++ it is good practice and greatly encouraged to replace constant expressions like the following example

#define PI 3.141592654
with
const double PI=3.141592654;

The reason is that you get proper typecasting and datatype handling.

Also

#define MAX(x,y) (x) > (y) ? (x) : (y)

Is not very nice because you can write

int i = 5
int max = MAX(i++, 6);

The preprocessor would replace that with:

int max = (i++) > (6) ? (i++) : (6);

Which is clearly not going to give the intended result.

Instead, MAX should be a function (not a macro). If it's a function it can also provide the type in the parameter.

I have seen the preprocessor used for all sorts of interesting things. Like language keyword declaration. It can aid in readability in this case.

In short, use the preprocessor for things that must happen at compile type such as conditional includes directives. Avoid using it for constants. Avoid macros and instead use functions where possible.

Answer 4

But why bother with the concept of preprocessor directives at all? Is it not possible to write equivalent code that can assign values to constants, define subroutines/function/macros and handle errors?

Its use is very low in C++, features of the language were created to avoid problems associated with the preprocessor.

I guess I ultimately want to know when it is good practice to use such preprocessor directives, and when it is not.

In general C++ sources, it is often seen as poor practice - particularly when there is a mean to do it using other language features. It is required for some things (i.e. platform/build dependent programs and generative programs). In short, there's usually a replacement which scales well. (such as constant define as enum, or inline templates instead of macros). If you find yourself using one and you are not sure, then just ask/search if there is a better way to declare this_code_snippet in C++, without the preprocessor.

Answer 5

It is used most frequently for two things which will be harder to organize without it:

1. Include guards.
2. Different sections of code for different platforms.

Answer 6

Answer 1: conditional code that has to vary depending on what sort of computer it works on.

Answer 2: enabling and disabling language extensions and compatibility features seen at compile time.

The preprocessor came from C, where there were many thing you could not express. Good C++ code finds less reasons to use it than C code did, but sadly it's not quite useless.