Dirty tricks with macros C ++

• Safe method call
• Unused variables
• String conversion
• Comma in the macro argument
• Endless cycle

Some useful links

Slight cultural difference

#define FUNC(x, y) ((x)^(y)) 

 #define VALUE 1 

What is good and what is bad

1. Macros cannot be debugged

   First, in fact, you can:

   Go to either "Properties". Under Configuration Properties-> C / C ++ -> Preprocessor, set "Generate Prepared File", you prefer. This will show what your macro expands to in context. If you need to compile a code, you need to go.

   So, it would be more correct to say that “macros are difficult to debug”. But, nevertheless, the problem with debugging macros exists.
   
   To determine if the macro you are using needs debugging, consider whether there is something in it that you want to push a breakpoint for. This can be a change in values ​​obtained through parameters, a declaration of variables, a change in objects or data from the outside, and the like.
   Solutions to the problem:
   
   • get rid of macros completely by replacing them with functions (you can inline if this is important),
   • the logic of macros is transferred to functions, and the macros themselves must be made responsible only for the transfer of data to these functions,
   • use only macros that do not require debugging.
2. When deploying a macro, strange side effects may occur.

   In order to show which side effects are involved, an example is usually given with arithmetic operations. I, too, will not depart from this tradition:
   

    #include <iostream> #define SUM(a, b) a + b int main() { //    x? int x = SUM(2, 2); std::cout << x << std::endl; x = 3 * SUM(2, 2); std::cout << x << std::endl; return 0; } 

   In the output we expect 4 and 12, and we get 4 and 8. The fact is that the macro simply substitutes the code where indicated. And in this case, the code will look like this:
   

    int x = 3 * 2 + 2; 

   This is a side effect. For everything to work, as expected, you need to change our macro:
   

    #include <iostream> #define SUM(a, b) (a + b) int main() { //    x? int x = SUM(2, 2); std::cout << x << std::endl; x = 3 * SUM(2, 2); std::cout << x << std::endl; return 0; } 

   Now is true. But that is not all. Let's go to the multiplication:
   

    #define MULT(a, b) a * b 

   Immediately, we write it “correctly”, but use it a little differently:
   

    #include <iostream> #define MULT(a, b) (a * b) int main() { //    x? int x = MULT(2, 2); std::cout << x << std::endl; x = MULT(3, 2 + 2); std::cout << x << std::endl; return 0; } 

   Deja vu: again we get 4 and 8. In this case, the expanded macro will look like:
   

    int x = (3 * 2 + 2); 

   That is, now we need to write:
   

    #define MULT(a, b) ((a) * (b)) 

   Use this version of the macro and voila:
   

    #include <iostream> #define MULT(a, b) ((a) * (b)) int main() { //    x? int x = MULT(2, 2); std::cout << x << std::endl; x = MULT(3, 2 + 2); std::cout << x << std::endl; return 0; } 

   Now everything is correct.
   
   If we abstract from arithmetic operations, then, in general, when writing macros, we need
   

   • brackets around the whole expression
   • brackets around each of the macro parameters

   That is, instead
   

    #define CHOOSE(ifC, chooseA, otherwiseB) ifC ? chooseA : otherwiseB 

   must be
   

    #define CHOOSE(ifC, chooseA, otherwiseB) ((ifC) ? (chooseA) : (otherwiseB)) 

   
   This problem is aggravated by the fact that not all types of parameters can be wrapped in brackets (the real example will be further in the article). Because of this, it is quite difficult to make high-quality macros.
   
   In addition, as the encyclopedist recalled in the comments, there are times when brackets do not save:
   

   In the paragraph about side effects, you still forgot to mention a frequent problem - macros can calculate their arguments several times. In the worst case, this leads to strange side effects, and more easily, to performance problems.
   Example
   
   

    #define SQR(x) ((x) * (x)) y = SQR(x++); 

   Solutions to the problem:
   
   • drop macros in favor of functions
   • use macros with a clear name, a simple implementation and well-placed brackets, so that a programmer using such a macro can easily understand how to use it correctly.
3. Macros have no namespace

   If any macro is declared, it is not only global, but also simply will not allow to use something with the same name (the implementation of the macro will always be substituted). The most probably well-known example is the problem with min and max under Windows .
   The solution to the problem is to choose names for macros that are less likely to intersect with something, for example:
   
   • names in UPPERCASE, they can usually intersect only with other macro names,
   • names with a prefix (the name of your project, namespace, something else unique), intersection with other names will be possible with very little probability, but it will be a little more difficult for people to use such macros outside of your project.
4. Macros can do something that you do not suspect.

   In fact, this is the problem of choosing a name for a macro. Let's say we take the same example, which is given in the answer by reference:
   

    #define begin() x = 0 #define end() x = 17 ... a few thousand lines of stuff here ... void dostuff() { int x = 7; begin(); ... more code using x ... printf("x=%d\n", x); end(); } 

   Here there are incorrectly chosen names that are misleading. If the macros were called set0toX () and set17toX () or something similar, problems would have been avoided.
   Solutions to the problem:
   
   • correctly call macros,
   • replace macros with functions
   • Do not use macros that implicitly change anything.

• do not require debugging (there’s simply no need to put a breakpoint inside)
• do not have side effects when unfolding (everything is wrapped in brackets)
• do not conflict with names anywhere (such kind of names are chosen, which with a small degree of probability will be used by someone else)
• do not change anything implicitly (the name accurately reflects what the macro does, and all work with the surrounding code, if possible, is carried out only through parameters and “return value”)

Safe method call

 #define prefix_safeCall(value, object, method) ((object) ? ((object)->method) : (value)) #define prefix_safeCallVoid(object, method) ((object) ? ((void)((object)->method)) : ((void)(0))) 

 #define prefix_safeCall(defaultValue, objectPointer, methodWithArguments) ((objectPointer) ? ((objectPointer)->methodWithArguments) : (defaultValue)) #define prefix_safeCallVoid(objectPointer, methodWithArguments) ((objectPointer) ? static_cast<void>((objectPointer)->methodWithArguments) : static_cast<void>(0)) 

 prefix_safeCallVoid(getObject(), method()); 

 #define prefix_safeCall(defaultValue, objectPointer, methodWithArguments)\ [&](auto&& ptr) -> decltype(auto)\ {\ return ptr ? (ptr->methodWithArguments) : (defaultValue);\ }\ (objectPointer) #define prefix_safeCallVoid(objectPointer, methodWithArguments)\ [&](auto&& ptr)\ {\ if(ptr)\ (ptr->methodWithArguments); \ }\ (objectPointer) 

 #define prefix_safeCallBaseExpression(defaultValue, objectPointer, methodWithArguments)\ ((ptr) ? ((ptr)->methodWithArguments) : (defaultValue)) #define prefix_safeCall(defaultValue, objectPointer, methodWithArguments)\ [&](decltype((objectPointer))&& ptr)\ -> decltype(prefix_safeCallBaseExpression(defaultValue, ptr, methodWithArguments))\ {\ return prefix_safeCallBaseExpression(defaultValue, ptr, methodWithArguments);\ }\ (objectPointer) #define prefix_safeCallVoid(objectPointer, methodWithArguments)\ [&](decltype((objectPointer))&& ptr)\ {\ if (ptr)\ (ptr->methodWithArguments);\ }\ (objectPointer) 

 auto somePointer = ...; if(somePointer) somePoiter->callSomeMethod(); 

 auto somePointer = ...; prefix_safeCallVoid(somePointer, callSomeMethod()); 

 auto somePointer = ...; auto x = prefix_safeCall(0, somePointer, callSomeMethod()); 

Unused variables

 #define prefix_unused(variable) ((void)variable) 

 #define prefix_unused1(variable1) static_cast<void>(variable1) #define prefix_unused2(variable1, variable2) static_cast<void>(variable1), static_cast<void>(variable2) #define prefix_unused3(variable1, variable2, variable3) static_cast<void>(variable1), static_cast<void>(variable2), static_cast<void>(variable3) #define prefix_unused4(variable1, variable2, variable3, variable4) static_cast<void>(variable1), static_cast<void>(variable2), static_cast<void>(variable3), static_cast<void>(variable4) #define prefix_unused5(variable1, variable2, variable3, variable4, variable5) static_cast<void>(variable1), static_cast<void>(variable2), static_cast<void>(variable3), static_cast<void>(variable4), static_cast<void>(variable5) 

 #define unused2(variable1, variable2) do {static_cast<void>(variable1); static_cast<void>(variable2);} while(false) 

 int main() { int a = 0; //  . prefix_unused(a); return 0; } 

String conversion

 #define prefix_stringify(something) std::string(#something) 

 std::cout << prefix_stringify("string\n") << std::endl; 

 std::cout << prefix_stringify(std::cout << prefix_stringify("string\n") << std::endl;) << std::endl; 

 std::cout << prefix_stringify(#define prefix_stringify(something) std::string(#something) std::cout << prefix_stringify("string\n") << std::endl;) << std::endl; 

 std::cout << prefix_stringify(#define prefix_stringify(something) std::string(#something)\nstd::cout << prefix_stringify("string\n") << std::endl;) << std::endl; 

Comma in macro parameter

 #define prefix_singleArgument(...) __VA_ARGS__ 

 #define FOO(type, name) type name FOO(prefix_singleArgument(std::map<int, int>), map_var); 

Endless cycle

 #define forever() for(;;) 

 #define ever (;;) for ever { ... } 

 int main() { bool keyPressed = false; forever() { ... if(keyPressed) break; } return 0; } 

Conclusion