What About Accessors?

There are people who will argue that one-line accessor functions (like "X& Y::f(){ return myX_; }") are a reasonable exception and could or should be automatically inlined. I understand the reasoning, but be careful. At the very least, all inlined code increases coupling. So, unless you're certain in advance that inlining will help, there's no harm in deferring that decision to profiling time. If at that point, a profiler does point out that inlining will help, at least you know that what you're doing is worth doing, and you've deferred the coupling and possible build overhead until you know it will really matter. Not a bad deal, that.

Avoid inlining or detailed tuning until performance profiles prove the need.

When and how should you decide to 'inline' a function?

The answer is the same as when to apply any other optimization: after a profiler tells you to, and not a minute sooner. There are a few valid exceptions to this guideline for cases in which you would reasonably inline right away, such as for an empty function that's likely to stay empty, or when you're absolutely forced to—for example, when writing a non-exported template.

Bottom line, inlining always costs

Does making a function inline increase efficiency?

Not necessarily. First off, if you tried to answer this question without first asking what you want to optimize, you fell into a classic trap. The first question has to be: "What do you mean by efficiency?" Does the above question mean program size? Memory footprint? Execution time? Development speed? Build time? Or something else? Second, contrary to popular opinion, inlining can improve or worsen any of those aspects of efficiency: Program size. Many programmers