Why should I use inline functions instead of plain old #define macros?, C++ FAQ

C++ FAQ / Section 9 / FAQ 9.5

Section 9:

9.1	What's the deal with `inline` functions?
9.2	What's a simple example of procedural integration?
9.3	Do `inline` functions improve performance?
9.4	How can `inline` functions help with the tradeoff of safety vs. speed?
9.5	Why should I use `inline` functions instead of plain old `#define` macros?
9.6	How do you tell the compiler to make a non-member function `inline`?
9.7	How do you tell the compiler to make a member function `inline`?
9.8	Is there another way to tell the compiler to make a member function `inline`?
9.9	What's a good way to define inline member functions outside the class body?

[9.5] Why should I use inline functions instead of plain old #define macros?

Because #define macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4. Sometimes you should use them anyway, but they're still evil.

Unlike #define macros, inline functions avoid infamous macro errors since inline functions always evaluate every argument exactly once. In other words, invoking an inline function is semantically just like invoking a regular function, only faster:

// A macro that returns the absolute value of i
#define unsafe(i)  \
        ( (i) >= 0 ? (i) : -(i) )

// An inline function that returns the absolute value of i
inline
int safe(int i)
{
  return i >= 0 ? i : -i;
}

int f();

void userCode(int x)
{
  int ans;

  ans = unsafe(x++);   // Error! x is incremented twice
  ans = unsafe(f());   // Danger! f() is called twice

  ans = safe(x++);     // Correct! x is incremented once
  ans = safe(f());     // Correct! f() is called once
}

Also unlike macros, argument types are checked, and necessary conversions are performed correctly.

Macros are bad for your health; don't use them unless you have to.