What is a macro in C ++


Macros are a more or less large number of instructions that are grouped under a short name and can be used as a unit. Macros are usually offered in assembly languages, but are also available in some higher programming languages, for example in C / C ++ through the C preprocessor. Finally, there are also pure macro languages โ€‹โ€‹(such as the Macroprocessor m4 from Unix / Linux) that can be used as a tool for the systematic transformation of text files.

With regard to a macro, a distinction is made between these definition, usually once and BEFORE the first use (possibly also in include files) and its Uses (0 to any number of times).

General information on macros [edit]

Are particularly flexible parameterizable macros. The macro definition can then be seen as a template in which some places have been kept open in order to be filled later when using the macro. When programming, parameterizable macros have a certain similarity to subroutines (with parameters), but they are executed differently at the time of compilation and are defined with regard to the parameter values.

When programming microcontrollers, it is sometimes necessary to trade off between the use of subroutines and macros. Universally reusable and therefore still configurable to a certain extent program parts can be more efficient than subroutines in the form of macros. However, the following requirements must be met:

  1. The "variable" part (= current values โ€‹โ€‹of the parameters) must be able to be specified during compilation. If this point is not guaranteed, (parameterized) macros are completely ruled out.
  2. The macro is only used once in this exact form. Whether the multiple use of a macro with identical parameters is an advantage or disadvantage compared to a subroutine depends on what is to be optimized. In terms of execution speed, the macro is advantageous; when it comes to small code sizes, the subroutine is almost always better. The exception to this rule are trivial macros that generate less machine code than the command for a subroutine jump and the necessary parameter transfer.

Macros vs. inline functions [edit]

Instead of using a macro, a function can also be provided with the keyword "inline". This is a hint for the compiler that it should insert the code of the inline function directly at the point at which the function is called. It is up to the compiler to decide whether it will follow this advice[1][2].

Advantages of inline functions [edit]

Type security
The compiler can check the types of parameters and detect errors. Anything can be passed to a macro, which then leads to strange error messages when compiling or, worse, strange program behavior. Examples can be found in the article C preprocessor.
Parameter evaluation
The parameters are evaluated before the inline function is called. Inline functions help to avoid unpleasant surprises, especially if the parameter evaluation has side effects such as post-increment or a parameter is used multiple times. Here, too, reference is made to the article C preprocessor for examples.
Macros are just hacks
Macros should be avoided because they make debugging difficult and they contradict structured programming. In particular, complex, supposedly ingenious and nested macros can be completely incomprehensible to others or to yourself after a while.

Advantages of macros [edit]

Text replacement
Macros are a little more flexible, as certain code snippets that often occur can be grouped together. A valid C code must only result after the macro has been installed by the preprocessor. This means that macros can be used very flexibly in some places.
Macros are awesome
With macros you can display some things in a compact way and in particular avoid annoying code repetitions or wait at a central location.

So now macros or inline functions? [Edit]

It is probably partly a question of faith that can be debated for a long time. Some say that macros have always been used and that they simply belong to C (and to assembler anyway). Others see it as a legacy from times when code was written in Assember, the compilers were bad and a goto wasn't bad ....

However, experience with larger projects (especially in the non-uC or 32-bit uC area) shows that macro should be used with care. The more abstract the module, the fewer macros should be used. Nevertheless, macros are particularly useful if you are programming directly on the hardware and are far away from structured, object-oriented programming. There is simply no getting around one or the other manually optimized hack, because otherwise the compiler simply cannot do it after all.

Nevertheless, it should be warned at this point not to get lost in what is supposed to be a great macro without sleeping over the whole night. Every supposed optimization via macro hacks should really be an optimization in the end.

At this point, the author expects heated debates and practical examples about what compilers just can't do ... :)

Footnotes [edit]

See also [edit]