C++ inline functions: which statements are correct about their impact?

Introduction / Context:
Inlining replaces a function call with the function’s body at the call site (subject to compiler heuristics). This can remove call overhead and enable further optimizations such as constant propagation and dead code elimination. However, duplicating the body across call sites can increase code size, affecting instruction cache behavior.

Given Data / Assumptions:

• Inline is a request to the optimizer; compilers may ignore it.
• Small, frequently called functions are the best candidates.
• We consider typical desktop and embedded targets with caches.

Concept / Approach:

Inlining often speeds up execution by eliminating call/return overhead and enabling interprocedural optimizations. At the same time, it usually increases code size because the function’s body is replicated at each call site. Whether performance improves depends on many factors: code size growth can actually hurt instruction cache locality, especially on tight embedded systems, leading to neutral or even negative performance changes. Therefore, the commonly accepted trade-off is “can be faster” and “often larger.”

Step-by-Step Solution:

Verification / Alternative check:

Benchmark two builds: one with forced inlining of a hot, tiny function and one without. You will often see modest speedups and measurable code growth; for large functions, growth can dominate and even hurt speed due to cache misses.

Why Other Options Are Wrong:

“Slows down execution” is not generally true; it may happen in some cases but is not the defining characteristic.

Choosing only A or only C ignores the dual effect intrinsic to inlining.

Common Pitfalls:

• Forcing inline on large functions indiscriminately.
• Confusing the inline keyword’s ODR/linkage meaning with “always inline.” Modern compilers decide independently.

Final Answer:

Both A and C.