Is there any difference between operators and other methods to make inline in C++? I have searched for it, but it is not a common question, as I see. Has anyone a strong reason to use it or avoid? Note: clearly, I mean inline operators when they are small.
-
4Well inlining is not up to you but the compiler, unless you use compiler-specific things. So the answer for C++ is: doesn't matter, can't control it. – GManNickG Jan 09 '13 at 00:50
-
@GManNickG: That should be an answer instead of a comment! – K-ballo Jan 09 '13 at 00:51
-
1@K-ballo: Well, that would take effort in then explaining how the `inline` keyword doesn't actually control inlining and meh, I've gotten lazy. :) – GManNickG Jan 09 '13 at 00:54
-
1The only strong reason I could imagine is that inlining the code disturbs readability a lot (depending on the necessary amount of code). Operators are likely to appear bunchwise. – πάντα ῥεῖ Jan 09 '13 at 00:57
-
2See also [this SO question](http://stackoverflow.com/questions/145838/benefits-of-inline-functions-in-c). – Richard Jan 09 '13 at 01:01
3 Answers
While this could vary between compilers, I'd expect that from the compiler's viewpoint, an operator is just another function with a somewhat unusual name that allows the syntax of the source code to look a little different.
Nonetheless, by the time the code generator part of the compiler runs, I'd expect any difference between an overloaded operator and another function (that did the same things) to have disappeared.
As such, declaring it as inline
or defining it within the body of a class definition will have just as much (little, depending on your viewpoint) with an operator overload as any other function. I'd normally expect that effect to be pretty minimal in both cases -- at least when optimization is enabled, most compilers pretty much ignore the inline
keyword and make their own decision about what to expand inline (and what not to) on their own.
Note that in one way the compiler can't ignore the inline
keyword though -- there are some special modifications to the "one definition rule" that must be observed, regardless of whether a function is actually expanded inline or not.

- 476,176
- 80
- 629
- 1,111
-
2An operator overload **is** just another function, there are no differences – K-ballo Jan 09 '13 at 00:56
-
2@K-ballo: From the standard's viewpoint, your clearly right. I'd *expect* it to be correct from the compiler's viewpoint as well -- but a compiler *could* apply different rules about inlining based on whether something was an operator overload (though I'd be surprised to see it in practice). – Jerry Coffin Jan 09 '13 at 00:59
-
A compiler also *could* apply different rules about inlining depending any other criteria, such as the number of arguments that the function accepts, or whether its name matches a certain pattern. An overloaded operator is nothing special in that regard. – Wyzard Jan 09 '13 at 01:13
You can use the inline
keyword to suggest to the compiler that a function be made inline.
The compiler is not obligated to obey this request.
Operators are similar - they may or may not be inlined.
Since the compiler can't be forced to inline there are probably no strong reasons to use or avoid using inlining hints. Because that is all they are: hints.
In Visual C++ you can use the __forceinline
keyword to force inlining, the result is larger code and potential loss of performance. It's common in well-designed systems that eliminating options (by forcing things) often results in poorer performance. Even if you use this keyword, not every function can be successfully inlined.
GCC inlining is discussed here.

- 56,349
- 34
- 180
- 251
-
2"the result is larger code and potential loss of performance" [or it might be smaller code. Or faster](http://www.parashift.com/c++-faq/inline-and-perf.html) (I acknowledge that the linked page incorrectly assumes compilers always inline functions marked as `inline`) – Mooing Duck Jan 09 '13 at 01:13
As others mentioned if the compiler 'inlines' a method or not is usually not on your behalf, regarding usage of the inline
keyword and the optimization strategy of the compiler.
So I think the more important aspect is readability of header files, and operator
methods are likely to appear as sets of e.g. arithmetical operation implementations, where simple transformations can be used to build them up. So if I have to look into such header file, I'd like to see logically related sets of operator method signatures together to get an overview what's applicable or not.
A very simple example is the implementation of operator==()
and operator!=()
:
class A
{
public:
// Equality tests
//-----------------------------------------------------------------------
// This may involve some mor complex code that'll look ugly here
bool operator==(const A& rhs) const;
// Fine, this is a one liner. Code appears 'inline' (and is likely to be
// chosen for inlining by the compiler, no matter if inline keyword or not)
bool operator!=(const A& rhs) const { return !A::operator==(rhs); }
};

- 1
- 13
- 116
- 190