constexpr vs macro vs inline function

MACRO

Macros are a direct inheritance of C. One of the main flaws of macros is that they do not have typing, that is, you can pass any type of data to the macro and if the resulting code is compiled, you will not get errors:

#define SUMA(a,b) a+b

std::string c1 = "abc";
std::cout << SUMA(4,5) << std::endl; // 9
std::cout << SUMA(2,3.5) << std::endl; // 5.5
std::cout << SUMA(c1,"def") << std::endl; // abcdef
std::cout << SUMA("abc","def") << std::endl; // ERROR, no sabe cómo sumar dos const char*

Another problem with the macro is that it will explode the parameters literally, which can give strange results:

#define MACRO(a,b) (2*a+2*b)/(a+b)

int num1 = 4;
int num2 = 1;

std::cout << MACRO(num1++,num2) << std::endl
          << num1 << std::endl
          << num2 << std::endl;

Someone might think that the output of this code is going to be:

2 -> (4*2+2*1)/(4+1) = (8+2)/4 = 10/5 = 2
5 -> num1++ = 4+1 = 5
1 -> num2 = 1

However the actual output is (in my case):

1 -> ???
6 -> ((2*num++)+2*b)/((num++)+b) -> hay dos incrementos
1 -> num2 = 1

I have not calculated the first result manually because the final result will depend on the compiler (and the problem is with the postincrement):

• The compiler processes the postincrements after the result has been calculated:

  (2*4+2*1)/(4+1) -> 2
  

• The compiler processes (2*4)and calculates a postincrement:

  (2*4+2*1)/(5+1) -> 1
  

• The compiler processes the equation backwards and computes a postincrement after (4+1):

  (2*5+2*1)/(4+1) -> 2
  

It is easy to guess that this example can be complicated as much as we want:

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

std::cout << MACRO(4+5,2) << std::endl;

What's the score? The correct answer is:

4+5*4+5*2 = 4+20+10 = 34

For all these problems, macros should be avoided in the vast majority of situations (and others that are not listed).

INLINE FUNCTIONS

To avoid all these problems derived from the macros, the functions arose inline. An inline function is strongly typed and guarantees the stability of the parameters (pre-increments, post-increments, etc. are calculated once). The above code using an inline function:

inline int func(int a, int b)
{ return a*a*b; }

std::cout << func(4+5,2) << std::endl;

The result would now be:

a = 9, b = 2
a*a*b = 9*9*2 = 162

And if we convert the postincrements example:

inline int func(int a, int b)
{ return (2*a+2*b)/(a+b); }

int num1 = 4;
int num2 = 1;

std::cout << func(num1++,num2) << std::endl
          << num1 << std::endl
          << num2 << std::endl;

The result would ALWAYS be :

2 -> (2*4+2*1)/(4+1) = 10/5 = 2
5 -> a++ = 4+1
1 -> b = 1

CONSTEXPR FUNCTIONS

The constexpr functions appeared in the C++11 standard. They are similar to inline functions with the addition that the result of the operation " can " be precomputed at compile time. In itself this may not seem like an obvious advantage, since inline functions can currently also be optimized in the same direction, as shown in the following example:

inline int factorialInline(int n)
{
    return n <= 1? 1 : (n * factorialInline(n - 1));
}

constexpr int factorialConstExpr(int n)
{
    return n <= 1? 1 : (n * factorialConstExpr(n - 1));
}

extern void funcExtern(int);

int main()
{
  funcExtern(factorialInline(10));
  funcExtern(factorialConstExpr(10));
}

Whose assembly output (clang 3.9.1 -std=c++11 -O3) is as follows:

push    rax
mov     edi, 3628800
call    funcExtern(int)
mov     edi, 3628800
call    funcExtern(int)
xor     eax, eax
pop     rcx
ret

There you can see how the result of both functions ( 10! = 3628800) has been precalculated at compile time.

What is the difference then between using inlineor constexpr?

The difference is that constexpr, due to the restrictions that it implements (I do not intend to list them because this post is not a course on constexpr), it allows to ensure better optimizations in the code. Let's look at another example:

inline int factorialInline(int n)
{
    return n <= 1? 1 : (n * factorialInline(n - 1));
}

constexpr int factorialConstExpr(int n)
{
    return n <= 1? 1 : (n * factorialConstExpr(n - 1));
}

extern void funcExtern(int);

const int valor1 = factorialInline(10);
const int valor2 = factorialConstExpr(10);

int main()
{
  funcExtern(valor1);
  funcExtern(valor2);
}

Assembly code:

main:                                   # @main
    push    rax
    mov     edi, dword ptr [rip + valor1]
    call    funcExtern(int)
    mov     edi, 3628800
    call    funcExtern(int)
    xor     eax, eax
    pop     rcx
    ret

_GLOBAL__sub_I_example.cpp:             # @_GLOBAL__sub_I_example.cpp
    mov     dword ptr [rip + valor1], 3628800
    ret

Here you can see how the function inlineinvolves two copy operations (one to store the result in valor1and one to call funcExtern), while in the version case constexprthe compiler has the luxury of directly using the value where it is required.

In subsequent standards, the capabilities of constexprhave increased, so it is increasingly being reinforced as the most powerful alternative.

CONCLUSION

The best thing to do, based on my experience, is to prioritize features constexpr. When this route cannot be used, for whatever reason, the second option should be functions inline, reserving macros for those situations where the previous two options are not available.