The implication of your question is that you're expecting different behavior based on the presence or absence of the inline keyword. Why do you think you would get a different result?
The original intent of the inline keyword was to serve as an indicator to the optimizer that inline substitution of a function is preferred over function call, that is, instead of executing the function call CPU instruction to transfer control to the function body, a copy of the function body is executed without generating the call. This avoids overhead created by the function call (passing the arguments and retrieving the result) but it may result in a larger executable as the code for the function has to be repeated multiple times.
The main current usage for specifying that a function not defined in a class is inline is to allow duplicate definitions in different compilation units (functions defined in a class are automatically inline).
the meaning of the keyword inline for functions came to mean "multiple definitions are permitted"
Unless you're using header files that contain function definitions that are to be included in different compilation units in the same solution - or your code is very performance sensitive - there's no benefit in using inline.
inline for performance tweaking is a tug-of-war battle with the compiler, where a few of the things that can happen include:
scenario 1: the compiler already decided to inline your function, so adding the keyword does nothing.
scenario 2: the compiler decided your function cannot (or even, should not) be inline, and ignored you.
there are other things that can go on as well but those two are common.
scenario 3: you told it to inline and it did, making the code actually slower than before because it was not a good choice.
visual studio has a force inline keyword that you can use if you want that extension. Other compilers may also, not sure what the commands are called.
you can also force inline with #includes (or macros, yuck) instead, but this would be a last resort and its been a long time for me since a compiler refused to inline something that needed it and the performance gains were worth the kludge force.
The original intent of the inline keyword was to serve as an indicator to the optimizer that inline substitution of a function is preferred over function call, that is, instead of executing the function call CPU instruction to transfer control to the function body, a copy of the function body is executed without generating the call. This avoids overhead created by the function call (passing the arguments and retrieving the result) but it may result in a larger executable as the code for the function has to be repeated multiple times.
Since this meaning of the keyword inline is non-binding, compilers are free to use inline substitution for any function that's not marked inline, and are free to generate function calls to any function marked inline. Those optimization choices do not change the rules regarding multiple definitions and shared statics...
C++17 changed the meaning of inline considerably:
cppreference wrote:
Because the meaning of the keyword inline for functions came to mean "multiple definitions are permitted" rather than "inlining is preferred", that meaning was extended to variables.
The example at the link shows an inlined function and a variable (C++17 or later required). Whether the function and variable are actually inlined is up to the compiler.