Skip to content

Remove the content of the contrast between inline functions and macros #4823

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 9 commits into from
Dec 13, 2023
115 changes: 47 additions & 68 deletions docs/cpp/inline-functions-cpp.md
Original file line number Diff line number Diff line change
@@ -1,24 +1,23 @@
---
title: "Inline Functions (C++)"
description: "The C++ inline keyword can be used to suggest inline functions to the compiler."
ms.date: 08/24/2022
ms.date: 12/07/2023
f1_keywords: ["__forceinline_cpp", "__inline_cpp", "inline_cpp", "__inline", "_inline", "__forceinline", "_forceinline"]
helpviewer_keywords: ["inline functions [C++], class members"]
ms.assetid: 355f120c-2847-4608-ac04-8dda18ffe10c
---
# Inline functions (C++)

The **`inline`** keyword tells the compiler to substitute the code within the function definition for every instance of a function call.
The **`inline`** keyword suggests that the compiler substitute the code within the function definition in place of each call to that function.

Using inline functions can make your program faster because they eliminate the overhead associated with function calls. The compiler can optimize functions expanded inline in ways that aren't available to normal functions.
In theory, using inline functions can make your program faster because they eliminate the overhead associated with function calls. Calling a function requires pushing the return address on the stack, pushing arguments onto the stack, jumping to the function body, and then executing a return instruction when the function finishes. This process is eliminated by inlining the function. The compiler also has different opportunities to optimize functions expanded inline versus those that aren't. A tradeoff of inline functions is that the overall size of your program can increase.

Inline code substitution occurs at the compiler's discretion. For example, the compiler won't inline a function if its address is taken or if it's too large to inline.
Inline code substitution is done at the compiler's discretion. For example, the compiler won't inline a function if its address is taken or if the compiler decides it's too large.

A function defined in the body of a class declaration is implicitly an inline function.

## Example

In the following class declaration, the `Account` constructor is an inline function. The member functions `GetBalance`, `Deposit`, and `Withdraw` aren't specified as **`inline`** but can be implemented as inline functions.
In the following class declaration, the `Account` constructor is an inline function because it is defined in the body of the class declaration. The member functions `GetBalance`, `Deposit`, and `Withdraw` are specified `inline` in their definitions. The `inline` keyword is optional in the function declarations in the class declaration.

```cpp
// Inline_Member_Functions.cpp
Expand Down Expand Up @@ -47,6 +46,7 @@ inline double Account::Withdraw( double Amount )
{
return ( balance -= Amount );
}

int main()
{
}
Expand All @@ -55,36 +55,34 @@ int main()
> [!NOTE]
> In the class declaration, the functions were declared without the **`inline`** keyword. The **`inline`** keyword can be specified in the class declaration; the result is the same.

A given inline member function must be declared the same way in every compilation unit. This constraint causes inline functions to behave as if they were instantiated functions. Additionally, there must be exactly one definition of an inline function.
A given inline member function must be declared the same way in every compilation unit. There must be exactly one definition of an inline function.

A class member function defaults to external linkage unless a definition for that function contains the **`inline`** specifier. The preceding example shows that you don't have to declare these functions explicitly with the **`inline`** specifier. Using **`inline`** in the function definition causes it to be an inline function. However, you can't redeclare a function as **`inline`** after a call to that function.
A class member function defaults to external linkage unless a definition for that function contains the **`inline`** specifier. The preceding example shows that you don't have to declare these functions explicitly with the **`inline`** specifier. Using **`inline`** in the function definition suggests to the compiler that it be treated as an inline function. However, you can't redeclare a function as **`inline`** after a call to that function.

## `inline`, `__inline`, and `__forceinline`

The **`inline`** and **`__inline`** specifiers instruct the compiler to insert a copy of the function body into each place the function is called.
The **`inline`** and **`__inline`** specifiers suggest to the compiler that it insert a copy of the function body into each place the function is called.

The insertion, called *inline expansion* or *inlining*, occurs only if the compiler's cost-benefit analysis shows it's worthwhile. Inline expansion minimizes the function-call overhead at the potential cost of larger code size.
The insertion, called *inline expansion* or *inlining*, occurs only if the compiler's own cost-benefit analysis shows it's worthwhile. Inline expansion minimizes the function-call overhead at the potential cost of larger code size.

The **`__forceinline`** keyword overrides the cost-benefit analysis and relies on the judgment of the programmer instead. Exercise caution when using **`__forceinline`**. Indiscriminate use of **`__forceinline`** can result in larger code with only marginal performance gains or, in some cases, even performance losses (because of the increased paging of a larger executable, for example).

The compiler treats the inline expansion options and keywords as suggestions. There's no guarantee that functions will be inlined. You can't force the compiler to inline a particular function, even with the **`__forceinline`** keyword. When you compile with **`/clr`**, the compiler won't inline a function if there are security attributes applied to the function.

For compatibility with previous versions, **`_inline`** and **`_forceinline`** are synonyms for **`__inline`** and **`__forceinline`**, respectively, unless compiler option [`/Za` \(Disable language extensions)](../build/reference/za-ze-disable-language-extensions.md) is specified.

The **`inline`** keyword tells the compiler that inline expansion is preferred. However, the compiler can create a separate instance of the function (instantiate) and create standard calling linkages instead of inserting the code inline. Two cases where this behavior can happen are:
The **`inline`** keyword tells the compiler that inline expansion is preferred. However, the compiler can ignore it. Two cases where this behavior can happen are:

- Recursive functions.

- Functions that are referred to through a pointer elsewhere in the translation unit.

These reasons may interfere with inlining, *as may others*, at the discretion of the compiler; you shouldn't depend on the **`inline`** specifier to cause a function to be inlined.
These reasons may interfere with inlining, *as may others*, as determined by the compiler. Don't depend on the **`inline`** specifier to cause a function to be inlined.

Rather than expand an inline function defined in a header file, the compiler may create it as a callable function in more than one translation unit. The compiler marks the generated function for the linker to prevent one-definition-rule (ODR) violations.

As with normal functions, there's no defined order for argument evaluation in an inline function. In fact, it could be different from the argument evaluation order when passed using the normal function-call protocol.

The [`/Ob`](../build/reference/ob-inline-function-expansion.md) compiler optimization option helps to determine whether inline function expansion actually occurs.

Use the [`/Ob`](../build/reference/ob-inline-function-expansion.md) compiler optimization option to influence whether inline function expansion actually occurs.\
[`/LTCG`](../build/reference/ltcg-link-time-code-generation.md) does cross-module inlining whether it's requested in source code or not.

### Example 1
Expand Down Expand Up @@ -121,28 +119,20 @@ private:

The **`__inline`** keyword is equivalent to **`inline`**.

Even with **`__forceinline`**, the compiler can't inline code in all circumstances. The compiler can't inline a function if:
Even with **`__forceinline`**, the compiler can't inline a function if:

- The function or its caller is compiled with **`/Ob0`** (the default option for debug builds).

- The function and the caller use different types of exception handling (C++ exception handling in one, structured exception handling in the other).

- The function has a variable argument list.

- The function uses inline assembly, unless compiled with **`/Ox`**, **`/O1`**, or **`/O2`**.

- The function is recursive and doesn't have **`#pragma inline_recursion(on)`** set. With the pragma, recursive functions are inlined to a default depth of 16 calls. To reduce the inlining depth, use [`inline_depth`](../preprocessor/inline-depth.md) pragma.

- The function is virtual and is called virtually. Direct calls to virtual functions can be inlined.

- The program takes the address of the function and the call is made via the pointer to the function. Direct calls to functions that have had their address taken can be inlined.

- The function is also marked with the [`naked`](../cpp/naked-cpp.md) [`__declspec`](../cpp/declspec.md) modifier.

If the compiler can't inline a function declared with **`__forceinline`**, it generates a level 1 warning, except when:

- The function is compiled by using /Od or /Ob0. No inlining is expected in these cases.

- The function is defined externally, in an included library or another translation unit, or is a virtual call target or indirect call target. The compiler can't identify non-inlined code that it can't find in the current translation unit.

Recursive functions can be replaced with inline code to a depth specified by the [`inline_depth`](../preprocessor/inline-depth.md) pragma, up to a maximum of 16 calls. After that depth, recursive function calls are treated as calls to an instance of the function. The depth to which recursive functions are examined by the inline heuristic can't exceed 16. The [`inline_recursion`](../preprocessor/inline-recursion.md) pragma controls the inline expansion of a function currently under expansion. See the [Inline-Function Expansion](../build/reference/ob-inline-function-expansion.md) (/Ob) compiler option for related information.
Expand All @@ -152,12 +142,11 @@ Recursive functions can be replaced with inline code to a depth specified by the
For more information on using the **`inline`** specifier, see:

- [Inline Class Member Functions](../cpp/inline-functions-cpp.md)

- [Defining Inline C++ Functions with dllexport and dllimport](../cpp/defining-inline-cpp-functions-with-dllexport-and-dllimport.md)

## When to use inline functions

Inline functions are best used for small functions such as accessing private data members. The main purpose of these one- or two-line "accessor" functions is to return state information about objects. Short functions are sensitive to the overhead of function calls. Longer functions spend proportionately less time in the calling and returning sequence and benefit less from inlining.
Inline functions are best used for small functions, such as those that provide access to data members. Short functions are sensitive to the overhead of function calls. Longer functions spend proportionately less time in the calling and returning sequence and benefit less from inlining.

A `Point` class can be defined as follows:

Expand Down Expand Up @@ -191,72 +180,62 @@ int main()
Assuming coordinate manipulation is a relatively common operation in a client of such a class, specifying the two accessor functions (`x` and `y` in the preceding example) as **`inline`** typically saves the overhead on:

- Function calls (including parameter passing and placing the object's address on the stack)

- Preservation of caller's stack frame

- New stack frame setup

- Return-value communication

- Restoring the old stack frame

- Return

## Inline functions vs. macros

Inline functions are similar to macros, because the function code is expanded at the point of the call at compile time. However, inline functions are parsed by the compiler, and macros are expanded by the preprocessor. As a result, there are several important differences:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should keep this paragraph.

It seems to me that only "Inline functions are similar to macros" needs to be improved. They are very different to me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should also include the fact that inline substitution is not mandatory, it occurs at the compiler's discretion, in the list. Currently the wording is confusing. Inline functions are similar to macros, because the function code is expanded at the point of the call at compile time. sounds like the substitution always happens.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@codeworm96 Your idea is also my idea.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems to me that only "Inline functions are similar to macros" needs to be improved.

I agree. The statement is not that rigorous, and this causal relationship is also kind of far-fetched.

Copy link
Contributor Author

@Mq-b Mq-b Nov 24, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@frederick-vs-ja

Inline functions are similar to macros, because the function code is expanded at the point of the call at compile time.

I think we can just delete this paragraph and keep the last one:

inline functions are parsed by the compiler, and macros are expanded by the preprocessor.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Replace this paragraph with:

Inline functions vs. macros

inline functions are parsed by the compiler, and macros are expanded by the preprocessor.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The original wasn't good, and I'm not sure this is an improvement. 'Parsed by the compiler', although technically true, only indirectly conveys useful information. The crux of the matter that we are trying to get at is that the compiler, at its discretion, actually compiles the function and drops the code of the body into your code without the overhead of a function call, and with the benefit of actually going through the compiler so that language syntax and semantics are properly observed.
I see what the original author was trying to do here, but I think orienting the discussion about what an inline function is by comparing them with macros hurts more than it helps. I'll take a whack at redoing this section and we can see if it's an improvement.

A macro has some things in common with an `inline` function. But there are important differences. Consider the following example:

- Inline functions follow all the protocols of type safety enforced on normal functions.

- Inline functions are specified using the same syntax as any other function except that they include the **`inline`** keyword in the function declaration.

- Expressions passed as arguments to inline functions are evaluated once. In some cases, expressions passed as arguments to macros can be evaluated more than once.
```cpp
#include <iostream>

The following example shows a macro that converts lowercase letters to uppercase:
#define mult(a, b) a * b

```cpp
// inline_functions_macro.c
#include <stdio.h>
#include <conio.h>
inline int multiply(int a, int b)
{
return a * b;
}

#define toupper(a) ((a) >= 'a' && ((a) <= 'z') ? ((a)-('a'-'A')):(a))
int main()
{
std::cout << mult(5 + 5, 5 + 5) << std::endl; // outputs 35
std::cout << multiply(5 + 5, 5 + 5) << std::endl; // outputs 100

int main() {
char ch;
printf_s("Enter a character: ");
ch = toupper( getc(stdin) );
printf_s( "%c", ch );
std::cout << mult(2, 2.2) << std::endl>>; // no warning
std::cout << multiply(2, 2.2); // Warning C4244 'argument': conversion from 'double' to 'int', possible loss of data
}
// Sample Input: xyz
// Sample Output: Z
```

The intent of the expression `toupper(getc(stdin))` is that a character should be read from the console device (`stdin`) and, if necessary, converted to uppercase.
```Output
35
100
4.4
4
```

Because of the implementation of the macro, `getc` is executed once to determine whether the character is greater than or equal to `'a'`, and once to determine whether it's less than or equal to `'z'`. If it is in that range, `getc` is executed again to convert the character to uppercase. It means the program waits for two or three characters when, ideally, it should wait for only one
Here are some of the differences between the macro and the inline function:

Inline functions remedy the problem previously described:
- Macros are always expanded inline. However, an inline function is only inlined when the compiler determines it is the optimal thing to do.
- The macro may result in unexpected behavior. For example, the macro `mult(5+5,5+5)` expands to `5 + 5 * 5 + 5` resulting in 35, whereas the function evaluates `10 * 10`. You could address that by defining the macro as #define `mult(a, b) ((a)*(b))`.
- An inline function is subject to semantic processing by the compiler, whereas the preprocessor expands macros without that same benefit. Macros aren't type-safe, whereas functions are.
- Expressions passed as arguments to inline functions are evaluated once. In some cases, expressions passed as arguments to macros can be evaluated more than once. For example, consider the following:

```cpp
// inline_functions_inline.cpp
#include <stdio.h>
#include <conio.h>

inline char toupper( char a ) {
return ((a >= 'a' && a <= 'z') ? a-('a'-'A') : a );
}
#define sqr(a) ((a) * (a))

int main() {
printf_s("Enter a character: ");
char ch = toupper( getc(stdin) );
printf_s( "%c", ch );
int main()
{
int c = 5;
std::cout << sqr(c++) << std::endl; // outputs 25
std::cout << c << std::endl; // outputs 7!
}
```

```Output
Sample Input: a
Sample Output: A
```
In this example, the expression `c++` is evaluated twice; once for each occurrence of `a` in the macro expansion. Instead, if `sqr` were an inline function, the expression `c++` would be evaluated only once.

## See also

Expand Down