02 - object-like macros

Syntax

1
2
3
4
5
6
7
8
9

// object-like macros
#define identifier replacement-list
// function-like macros
#define identifier(parameters) replacement-list
#define identifier(parameters, ...) replacement-list
#define identifier(...) replacement-list

// undefine any macro
#undef identifier

The replacement-list is always optional (a macro may have "empty" definition and just exist). The identifier can be anything except:

• keywords

• identifiers with special meaning (list on https://en.cppreference.com/w/cpp/keyword)

• standard attribute tokens (list on https://en.cppreference.com/w/cpp/language/attributes#Standard_attributes)

In practice, implementations allow such macros (preprocessor doesn't understand C++ grammar and keywords after all) but output a warning - the standard doesn't want programmers to hijack core parts of the language by the preprocessor text replacement mechanism.

In the example below you can see both object-like and function-like macros in action. The preprocessor is capable of basic math operations - these are typically used to check the level of available features.

1
2
3
4
5
6
7
8
9
10
11
12
13

// inside the library
#define LIB_VERSION_ENCODE(x, y, z) (10000 * x + 100 * y + z)
#define LIB_VERSION LIB_VERSION_ENCODE(2, 1, 3)

// some code that uses the library
#include <lib/version.hpp>
#if LIB_VERSION >= LIB_VERSION_ENCODE(2, 0, 0)
	// [...] code that uses newer approach
#elif LIB_VERSION >= LIB_VERSION_ENCODE(1, 6, 11)
	// [...] code that uses older approach
#else
	#error LIB_VERSION is too low!
#endif

#undef

Generally, there is no need to undefine previously defined macros - each translation unit that is a part of compilation process (source file + all files it includes) will run through separate preprocessor. Still, in some cases undefining may be desirable to affect other directives.

Unlike the C++ compiler (when it comes to duplicate definitions), the preprocessor reacts differently to conflicting directives:

• #define: if the identifier is already defined as any type of macro, the program is ill-formed unless the definitions are identical.

• #undef: if the identifier does not have associated macro, the directive is ignored.

Still, major compilers in both cases (duplicate definition, undefining non-existing macro) will issue warnings as such code while technically valid, typically indicates some mistake within preprocessor code.

When macro presence can not be easily predicted (which is the case on many platforms where supported features vary) one can prepend operations with checks to avoid warnings:

1
2
3
4
5
6
7

#ifndef ABC
#define ABC 1
#endif

#ifdef XYZ
#undef XYZ
#endif

Predefined macros

Several macros are defined by the C++ standard. You don't need to include any files to get them.

Implementation macros

Compilers provide a lot of information about the implementation in their own macros (not defined by the standard). Many are very useful for writing multiplatform code or code that takes advantage of certain features available only under special conditions. They typically provide information such as compiler name and version, target architecture and operating system, min/max/size/alignment of built-in types, endianess and other details.

For GCC and Clang, you can dump all of the predefined macros using a command like echo | g++ -x c++ -std=c++17 -dM -E - | sort (should work on Windows and many GNU/Linux distributions). See https://stackoverflow.com/q/2224334/4818802 for more info.

Constants

In both C and C++ various data must be a constant expression, e.g. an array size. C++ has extended const functionality so that some const-qualified objects could also be used for such purposes (this was before C++11 introduced constexpr) (the rules are somewhat complex so in C++11 and later code I strongly recommend constexpr).

In C however, const is not as powerful. This creates a necessity in C to use macros, otherwise the constants can not be used when a constant expression is needed:

1
2
3
4
5
6
7
8
9
10
11

// C approach
#define FOOBAR_SIZE 1024
char foobar[FOOBAR_SIZE]; // ok: size is a constant expression
for (int i = 0; i < FOOBAR_SIZE; ++i)
	// ... something with foobar[i]

// C++ approach (after C++11 would use constexpr)
const int foobar_size = 1024; // in C not treated as constant expression
char foobar[foobar_size]; // this would not be valid in C
for (int i = 0; i < foobar_size; ++i)
	// ... something with foobar[i]

In C using such macros is simply a necessity, otherwise there is no way to deal with code duplication. The language simply has no feature that solves this problem so the preprocessor text replacement is the only choice. In C++ the situation is much different so the following things are considered bad habits in C++:

• The use of macros when they are not needed. C++ has more powerful keywords and when macros can be avoided, they should be avoided.

• Naming constants using UPPERCASE when they are not macros. This may cause confusion and make regular code vulnerable to a macro of the same name. This is also mentioned in ES.9, NL.9 and Enum.5 points in Core Guidelines.

Exercise

Write a program that outputs Hello from C++XX where XX are last 2 digits of the year of the standard used.

1
2
3
4
5
6

#include <iostream>

int main()
{
	std::cout << "Hello from C++" << __cplusplus / 100 % 100;
}