I understand that inline by itself is a suggestion to the compiler, and at its discretion it may or may not inline the function, and it will also produce linkable object code.
I think that static inline does the same (may or may not inline) but will not produce linkable object code when inlined (since no other module could link to it).
Where does extern inline fit into the picture?
Assume I want to replace a preprocessor macro by an inline function and require that this function gets inlined (e.g., because it uses the __FILE__ and __LINE__ macros which should resolve for the caller but not this called function). That is, I want to see a compiler or linker error in case the function does not get inlined. Does extern inline do this? (I assume that, if it does not, there is no way to achieve this behavior other than sticking with a macro.)
Are there differences between C++ and C?
Are there differences between different compiler vendors and versions?
in K&R C or C89, inline was not part of the language. Many compilers implemented it as an extension, but there were no defined semantics regarding how it worked. GCC was among the first to implement inlining, and introduced the inline, static inline, and extern inline constructs; most pre-C99 compiler generally follow its lead.
GNU89:
inline: the function may be inlined (it's just a hint though). An out-of-line version is always emitted and externally visible. Hence you can only have such an inline defined in one compilation unit, and every other one needs to see it as an out-of-line function (or you'll get duplicate symbols at link time).
extern inline will not generate an out-of-line version, but might call one (which you therefore must define in some other compilation unit. The one-definition rule applies, though; the out-of-line version must have the same code as the inline offered here, in case the compiler calls that instead.
static inline will not generate a externally visible out-of-line version, though it might generate a file static one. The one-definition rule does not apply, since there is never an emitted external symbol nor a call to one.
C99 (or GNU99):
inline: like GNU89 "extern inline"; no externally visible function is emitted, but one might be called and so must exist
extern inline: like GNU89 "inline": externally visible code is emitted, so at most one translation unit can use this.
static inline: like GNU89 "static inline". This is the only portable one between gnu89 and c99
C++:
A function that is inline anywhere must be inline everywhere, with the same definition. The compiler/linker will sort out multiple instances of the symbol. There is no definition of static inline or extern inline, though many compilers have them (typically following the gnu89 model).
I believe you misunderstand __FILE__ and __LINE__ based on this statement:
because it uses the __FILE__ and
__LINE__ macros which should resolve for the caller but not this called
function
There are several phases of compilation, and preprocessing is the first. __FILE__ and __LINE__ are replaced during that phase. So by the time the compiler can consider the function for inlining they have already been replaced.
It sounds like you're trying to write something like this:
inline void printLocation()
{
cout <<"You're at " __FILE__ ", line number" __LINE__;
}
{
...
printLocation();
...
printLocation();
...
printLocation();
and hoping that you'll get different values printed each time. As Don says, you won't, because __FILE__ and __LINE__ are implemented by the preprocessor, but inline is implemented by the compiler. So wherever you call printLocation from, you'll get the same result.
The only way you can get this to work is to make printLocation a macro. (Yes, I know...)
#define PRINT_LOCATION {cout <<"You're at " __FILE__ ", line number" __LINE__}
...
PRINT_LOCATION;
...
PRINT_LOCATION;
...
Instead of answering "what does it do?", I'm answering "how do I make it do what I want?" There are 5 kinds of inlining, all available in GNU C89, standard C99, and C++. MSVC has some of them (note that I haven't tested the MSVC code)
always inline, unless the address is taken
Add __attribute__((always_inline)) to any declaration, then use one of the
below cases to handle the possibility of its address being taken.
You should probably never use this, unless you need its semantics (e.g. to affect the assembly in a certain way, or to use alloca). The compiler usually knows better than you whether it's worth it.
MSVC has __forceinline which appears mostly the same, but apparently it refuses to inline in quite a few common circumstances (e.g. when optimization is off) where other compilers manage just fine.
inline and emit a weak symbol (like C++, aka "just make it work")
__attribute__((weak))
void foo(void);
inline void foo(void) { ... }
Note that this leaves a bunch of copies of the same code lying around, and the linker picks one arbitrarily.
MSVC doesn't appear to have an exact equivalent in C mode, although there are a couple of similar things. __declspec(selectany) appears to be talking about data only, so might not apply to functions? There is also linker support for weak aliases, but does that work here?
inline, but never emit any symbol (leaving external references)
__attribute__((gnu_inline))
extern inline void foo(void) { ... }
MSVC's __declspec(dllimport), combined with an actual definition (otherwise unusual), supposedly does this.
emit always (for one TU, to resolve the preceding)
The hinted version emits a weak symbol in C++, but a strong symbol in either dialect of C:
void foo(void);
inline void foo(void) { ... }
Or you can do it without the hint, which emits a strong symbol in both languages:
void foo(void) { ... }
Generally, you know what language your TU is when you're providing the definitions, and probably don't need much inlining.
MSVC's __declspec(dllexport) supposedly does this.
inline and emit in every TU
static inline void foo(void) { ... }
For all of these except the static one, you can add a void foo(void) declaration above. This helps with the "best practice" of writing clean headers, then #includeing a separate file with the inline definitions. Then, if using C-style inlines, #define some macro differently in one dedicated TU to provide the out-of-line definitions.
Don't forget extern "C" if the header might be used from both C and C++!
There are also a couple of related things:
never inline
Add __attribute__((noinline)) to any declaration of the function.
MSVC has __declspec(noinline) but it is documented to only work for member functions. However, I've seen mention of "security attributes" which might prevent inlining?
force other functions to be inlined into this one if possible.
Add __attribute__((flatten)) to any declaration of the function.
Note that noinline is more powerful than this, as are functions whose definition isn't known at compile-time.
MSVC doesn't appear to have an equivalent. I've seen a single mention of [[msvc::forceinline_calls]] (applied to a statement or block), but it's not recursive.
The situation with inline, static inline and extern inline is complicated, not least because gcc and C99 define slightly different meanings for their behavior (and presumably C++, as well). You can find some useful and detailed information about what they do in C here.
Macros are your choice here rather than the inline functions. A rare occasion where macros rule over inline functions. Try the following: I wrote this "MACRO MAGIC" code and it should work! Tested on gcc/g++ Ubuntu 10.04
//(c) 2012 enthusiasticgeek (LOGGING example for StackOverflow)
#ifdef __cplusplus
#include <cstdio>
#include <cstring>
#else
#include <stdio.h>
#include <string.h>
#endif
//=========== MACRO MAGIC BEGINS ============
//Trim full file path
#define __SFILE__ (strrchr(__FILE__,'/') ? strrchr(__FILE__,'/')+1 : __FILE__ )
#define STRINGIFY_N(x) #x
#define TOSTRING_N(x) STRINGIFY_N(x)
#define _LINE (TOSTRING_N(__LINE__))
#define LOG(x, s...) printf("(%s:%s:%s)" x "\n" , __SFILE__, __func__, _LINE, ## s);
//=========== MACRO MAGIC ENDS ============
int main (int argc, char** argv) {
LOG("Greetings StackOverflow! - from enthusiasticgeek\n");
return 0;
}
For multiple files define these macros in a separate header file including the same in each c/cc/cxx/cpp files. Please prefer inline functions or const identifiers (as the case demands) over macros wherever possible.
C++ only:
As others have pointed out, macros (here __FILE__ and __LINE__) are evaluated before compiling and linking; So if you have a function that uses those and you want them to be different for each file, you need the opposite of inline. Since the __FILE__ and __LINE__ values are going to be different for each file, then the definition (body) of the function is going to be different for each file. But (non-static) inline means that if the function is defined in multiple translation units, they all must have the same definition.
You could define (not declare) a normal function or static or static inline function in a header file and include it anywhere you want. This way each translation unit (source file) gets its own copy of the function with different __FILE__ and __LINE__ values. Although, I think in the case of static inline, the inline keyword is useless in most cases.
Related
Based on the answer here, It is only needed to define the method inside header file in order to make it inline. So my question is, why there is inline keyword?
For example, if you want to define a free function inside a header (not a member function of a class), you will need to declare it inline, otherwise including it in multiple translation units will cause an ODR violation.
The usual approach is to declare the function in the header and define it in a separately compiled .cpp file. However, defining it in the header as an inline function allows every translation unit that includes it to have its definition available, which makes it easier for that function to actually be inlined; this is important if the function is heavily used.
The historical reason for the inline keyword is that older C compilers weren't as capable of optimising code as good quality modern C and C++ compilers are. It was therefore, originally, introduced to allow the programmer to indicate a preference to inline a function (effectively insert the function body directly into the caller, which avoids overheads associated with function calls). Since there was no guarantee that a compiler could inline the function (e.g. some compilers could only inline certain types of functions) the inline keyword was made a hint rather than a directive.
The other typical use of inline is not as discretionary - if a function is defined in multiple compilation units (e.g. because the containing header is #included more than once) then leaving off inline causes a violation of the one definition rule (and therefore in undefined behaviour). inline is an instruction to the compiler (which in turn probably emits instructions to the linker) to resolve such incidental violations of the one-definition rule, and produce a working program (e.g. without causing the linker to complain about multiple definitions).
As to why it is still needed, functionally, the preprocessor only does text substitution ... such as replacing an #include directive with contents of the included header.
Let's consider two scenarios. The first has two source files (compilation units) that do;
#include "some_header"
//some other functions needed by the program, not pertinent here
and
#include "some_header"
int main()
{
foo();
}
where some_header contains the definition
void foo() { /* whatever */ }
The second scenario, however, omits the header file (yes, people do that) and has the first source file as
void foo() { /* whatever */ }
//some other functions needed by the program, not pertinent here
and the second as;
void foo() { /* whatever */ }
int main()
{
foo();
}
In both scenarios, assume the two compilation units are compiled and linked together. The result is a violation of the one definition rule (and, practically, typically results in a linker error due to multiply defined symbols).
Under current rules of the language (specifically, the preprocessor only doing text substitution), the two scenarios are required to be EXACTLY functionally equivalent. If one scenario was to print the value 42, the so should the other. If one has undefined behaviour (as is the case here) so does the other.
But, let's say for sake of discussion, that there was a requirement that a function be magically inlined if it is defined in a header. The code in the two scenarios would no longer be equivalent. The header file version would have defined behaviour (no violation of the one definition rule) and the second would have undefined behaviour.
Oops. We've just broken equivalence of the two scenarios. That may not seem much, but programmers would practically have trouble understanding why one version links and the other doesn't. And they would have have no way of fixing that ... other than moving code into a header file.
That means, we need some way to make the two scenarios equivalent. This means there needs to be something in the code which makes them equivalent. Enter the inline keyword, and prefix it to the definitions of foo().
Now, okay, one might argue that the preprocessor should do something a bit more intelligent i.e. do more than simple text substitution. But, now you are on a slippery slope. The C and C++ standards do (at length) specify that the preprocessor does that. And changing that would introduce a cascade of other changes. Whether that is a good idea or not (and, certainly, there is some advocacy for eliminating the preprocessor from C++ entirely), that is a much bigger change, with numerous ramifications on the language, and on programmers (who, whether it is good or bad, can rely on the preprocessor behaving as it does).
Short answer. It's not required. Compilers generally ignore the inline keyword.
More comprehensive answers are already given in other questions, not to mention the second answer in the question you linked.
I defined a class in header file and implemented its function in same header file. I didn't put inline keyword with function definition because I think compiler will regard it as a inline function by default -- but inline is only a hint to compiler, right? What if compiler doesn't regard it as inline function because of its length? I never get error message 'multiple definitions' in reality.
struct tmp {
void print() {
...(very long)
}
};
I didn't put inline keyword with function definition because I think compiler will regard it as a inline function by default
Yes, member functions defined in the body of a class are implicitly inline. The keyword is not necessary.
inline is only a hint to compiler, right? What if compiler doesn't regard it as inline function because of its length?
Yes, sort of. Actually, the inline keyword has two meanings.
The first one is the one you are thinking of, the one that hints to the optimizer to inline the code in the function body at the call site. As you said, this is just a hint—the optimizer is free to ignore this request if it determines that it would be a performance pessimization to do so (or if it is unable to inline for some other technical reason). This meaning of the inline keyword is arguably obsolete. All optimizing compilers nowadays ignore the inline keyword because their authors consider their heuristics to be smarter than the programmer. This is almost always the case, making it rather pointless to try and second-guess the optimizer by marking your functions inline.
The second meaning of the inline keyword is to relax the one-definition rule (ODR), making it legal for there to be multiple definitions of the same function visible to the linker. (Although the behavior of the linker under such circumstances is an implementation detail, most of them will just arbitrarily pick one of the definitions. Which of course only works out well if they are all the same.) This meaning of the inline keyword is still very important, and explains why it is still used today in code.
This is the meaning that your code is benefitting from. Since member functions defined in the body of a class are implicitly marked inline, you do not get multiply-defined symbol errors from the linker.
If you had defined the function in the header file but not within the class definition—in other words, if you had done this:
struct tmp {
void print();
};
void tmp::print()
{ ... }
then you would start getting the multiply-defined symbol errors as soon as that header file was included in two or more compilands (i.e., translation units). This is where you would need to add the inline keyword on the function's definition, not because you want the compiler to "inline" it, but because you want to exempt yourself from the ODR.
EDIT #Leon (below) stated that my answer (reproduced below) was INCORRECT. The correct answer is described here - in short, if the compiler decides to not make a function inline, it still puts it in the object module. But the linker will then pick one of the (potentially many) copies in the different modules and discard all the others.
You are right: you won't get the "multiple definition" error because every time the compiler decides to not put a function inline, it makes the function static within the current module. That means that you could have a large number of copies of your large function littered through your code.
When one function calls another, and inlining is desired, is the order of the definitions of the two functions important? Assume that the two definitions occur in the same translation unit.
I am primarily interested in what the C++ standard says about it, if anything. However, if you have important information about the inlining behavior in specific compilers, I would be interested in that too. Please assume that no link-time optimization occurs (is disabled).
Specifically, are the following two versions equally likely to achieve inlining according to the C++ standard?
Version one:
inline void foo() { ... }
void bar() { ... foo(); ... }
Version two:
inline void foo();
void bar() { ... foo(); ... }
void foo() { ... }
EDIT: Please note that this question is not about the effectiveness of the inline keyword with respect to achieving inlining in general. I specifically ask about whether the standard says anything about the order of function definitions in relation to achieving inlining.
The C++ standard doesn't make any imposition here. Compilers are free to inline or not in any situation they see fit. The inline keyword may have no effect other than allowing multiple definitions of the same function.
Most compilers will be able to inline any function that is available to the translation unit, regardless of the order it appears in the source. Forward declarations generally only affect what names are available at a given point in the source file, not anything about the final output of the binary.
In reality the inline keyword has less to do with inlining code and more to do with allowing "legal violation" of the one definition rule. The main purpose of inline is to tell the compiler that a function may appear in multiple translation units (and that it will have the same definition in each one). This allows it to avoid multiple definition errors at the link stage.
Using the inline keyword is no guarantee that the compiler will inline the function at all - it's just a suggestion. Additionally many compilers will inline functions not marked as inline if the definition can be seen within the translation unit and the compiler deems it worthwhile. I strongly suspect that both examples you gave would both be inlined or not by a particular compiler.
In short, let the compiler decide whether or not to inline, and write your code in the most readable way.
I had a discussion with Johannes Schaub regarding the keyword inline.
The code there was this:
namespace ... {
static void someFunction() {
MYCLASS::GetInstance()->someFunction();
}
};
He stated that:
Putting this as an inline function may
save code size in the executable
But according to my findings here and here it wouldn't be needed, since:
[Inline] only occurs if the compiler's cost/benefit analysis show it to be profitable
Mainstream C++ compilers like Microsoft Visual C++ and GCC support an option that lets the compilers automatically inline any suitable function, even those not marked as inline functions.
Johannes however states that there are other benefits of explicitly specifying it. Unfortunately I do not understand them. For instance, he stated that And "inline" allows you to define the function multiple times in the program., which I am having a hard time understanding (and finding references to).
So
Is inline just a recommendation for the compiler?
Should it be explicitly stated when you have a small function (I guess 1-4 instructions?)
What other benefits are there with writing inline?
is it needed to state inline in order to reduce the executable file size, even though the compiler (according to wikipedia [I know, bad reference]) should find such functions itself?
Is there anything else I am missing?
To restate what I said in those little comment boxes. In particular, I was never talking about inlin-ing:
// foo.h:
static void f() {
// code that can't be inlined
}
// TU1 calls f
// TU2 calls f
Now, both TU1 and TU2 have their own copy of f - the code of f is in the executable two times.
// foo.h:
inline void f() {
// code that can't be inlined
}
// TU1 calls f
// TU2 calls f
Both TUs will emit specially marked versions of f that are effectively merged by the linker by discarding all but one of them. The code of f only exists one time in the executable.
Thus we have saved space in the executable.
Is inline just a recommendation for the compiler?
Yes.
7.1.2 Function specifiers
2 A function declaration (8.3.5, 9.3, 11.4) with an inline specifier declares an inline function. The inline
specifier indicates to the implementation that inline substitution of the function body at the point of call
is to be preferred to the usual function call mechanism. An implementation is not required to perform this
inline substitution at the point of call; however, even if this inline substitution is omitted, the other rules
for inline functions defined by 7.1.2 shall still be respected.
For example from MSDN:
The compiler treats the inline expansion options and keywords as suggestions. There is no guarantee that functions will be inlined. You cannot force the compiler to inline a particular function, even with the __forceinline keyword. When compiling with /clr, the compiler will not inline a function if there are security attributes applied to the function.
Note though:
3.2 One definition rule
3 [...]An inline function shall be defined in every translation unit in which it is used.
4 An inline function shall be defined in every translation unit in which it is used and shall have exactly
the same definition in every case (3.2). [ Note: a call to the inline function may be encountered before its
definition appears in the translation unit. —end note ] If the definition of a function appears in a translation
unit before its first declaration as inline, the program is ill-formed. If a function with external linkage is
declared inline in one translation unit, it shall be declared inline in all translation units in which it appears;
no diagnostic is required. An inline function with external linkage shall have the same address in all
translation units. A static local variable in an extern inline function always refers to the same object.
A string literal in the body of an extern inline function is the same object in different translation units.
[ Note: A string literal appearing in a default argument expression is not in the body of an inline function
merely because the expression is used in a function call from that inline function. —end note ] A type
defined within the body of an extern inline function is the same type in every translation unit.
[Note: Emphasis mine]
A TU is basically a set of headers plus an implementation file (.cpp) which leads to an object file.
Should it be explicitly stated when you have a small function (I
guess 1-4 instructions?)
Absolutely. Why not help the compiler help you generate less code? Usually, if the prolog/epilog part incurs more cost than having it inline force the compiler to generate them? But you must, absolutely must go through this GOTW article before getting started with inlining: GotW #33: Inline
What other benefits are there with writing inline?
namespaces can be inline too. Note that member functions defined in the class body itself are inline by default. So are implicitly generated special member functions.
Function templates cannot be defined in an implementation file (see FAQ 35.12) unless of course you provide a explicit instantiations (for all types for which the template is used -- generally a PITA IMO). See the DDJ article on Moving Templates Out of Header Files (If you are feeling weird read on this other article on the export keyword which was dropped from the standard.)
Is it needed to state inline in order to reduce the executable file
size, even though the compiler
(according to wikipedia [I know, bad
reference]) should find such functions
itself?
Again, as I said, as a good programmer, you should, when you can, help the compiler. But here's what the C++ FAQ has to offer about inline. So be wary. Not all compilers do this sort of analysis so you should read the documentation on their optimization switches. E.g: GCC does something similar:
You can also direct GCC to try to integrate all “simple enough” functions into their callers with the option -finline-functions.
Most compilers allow you to override the compiler's cost/benefit ratio analysis to some extent. The MSDN and GCC documentation is worth reading.
Is inline just a recommendation for the compiler?
Yes. But the linker needs it if there are multiple definitions of the function (see below)
Should it be explicitly stated when you have a small function (I guess 1-4 instructions?)
On functions that are defined in header files it is (usually) needed. It does not hurt to add it to small functions (but I don't bother). Note class members defined within the class declaration are automatically declared inline.
What other benefits are there with writing inline?
It will stop linker errors if used correctly.
is it needed to state inline in order to reduce the executable file size, even though the compiler (according to wikipedia [I know, bad reference]) should find such functions itself?
No. The compiler makes a cost/benefit comparison of inlining each function call and makes an appropriate choice. Thus calls to a function may be inlined in curtain situations and not inlined in other (depending on how the compilers algorithm works).
Speed/Space are two competing forces and it depends what the compiler is optimizing for which will determine weather functions are inlined and weather the executable will grow or shrink.
Also note if excessively aggressive inlining is used causing the program to expand too much, then locality of reference is lost and this can actually slow the program down (as more executable pages need to be brought into memory).
Multiple definition:
File: head.h
// Without inline the linker will choke.
/*inline*/ int add(int x, int y) { return x + y; }
extern void test()
File: main.cpp
#include "head.h"
#include <iostream>
int main()
{
std::cout << add(2,3) << std::endl;
test();
}
File: test.cpp
#include "head.h"
#include <iostream>
void test()
{
std::cout << add(2,3) << std::endl;
}
Here we have two definitions of add(). One in main.o and one in test.o
Yes. It's nothing more.
No.
You hint the compiler that it's a function that gets called a lot, where the jump-to-the-function part takes a lot of the execution time.
The compiler might decide to put the function code right where it gets called instead where normal functions are. However, if a function is inlined in x places, you need x times the space of a normal function.
Always trust your compiler to be much smarter than yourself on the subject of premature micro-optimization.
Actually, inline function may increase executable size, because inline function code is duplicated in every place where this function is called. With modern C++ compilers, inline mostly allows to programmer to believe, that he writes high-performance code. Compiler decides itself whether to make function inline or not. So, writing inline just allows us to feel better...
With regards to this:
And "inline" allows you to define the function multiple times in the program.
I can think of one instance where this is useful: Making copy protection code harder to crack. If you have a program that takes user information and verifies it against a registration key, inlining the function that does the verification will make it harder for a cracker to find all duplicates of that function.
As to other points:
inline is just a recommendation to compiler, but there are #pragma directives that can force inlining of any function.
Since it's just a recommendation, it's probably safe to explicitly ask for it and let the compiler override your recommendation. But it's probably better to omit it altogether and let the compiler decide.
The obfuscation mentioned above is one possible benefit of inlining.
As others have mentioned, inline would actually increase the size of the compiled code.
Yes, it will readily ignore it when it thinks the function is too large or uses incompatible features (exception handling perhaps). Furthermore, there is usually a compiler setting to let it automatically inline functions that it deems worthy (/Ob2 in MSVC).
It should be explicitly stated if you put the definition of the function in the header file. Which is usually necessary to ensure that multiple translation units can take advantage of it. And to avoid multiple definition errors. Furthermore, inline functions are put in the COMDAT section. Which tells the linker that it can pick just one of the multiple definitions. Equivalent to __declspec(selectany) in MSVC.
Inlined functions don't usually make the executable smaller. Since the call opcode is typically smaller than the inlined machined code, except for very small property accessor style functions. It depends but bigger is not an uncommon outcome.
Another benefit of in-lining (note that actual inlining is sometimes orthogonal to use of the "inline" directive) occurs when a function uses reference parameters. Passing two variables to a non-inline function to add its first operand to the second would require pushing the value of the first operand and the address of the second and then calling a function which would have to pop the first operand and address of the second, and then add the former value indirectly to the popped address. If the function were expanded inline, the compiler could simply add one variable to the other directly.
Actually inlining leads to bigger executables, not smaller ones.
It's to reduce one level of indirection, by pasting the function code.
http://www.parashift.com/c++-faq-lite/inline-functions.html
I've always wondered, if it's good or bad practice to define trivial method twice, depending
if the project's on debug / release -state. This is for inlining them. For instance, Foo.h:
class Foo
{
public:
...
const bool& IsBoolean() const;
private:
bool _boolean;
};
#ifndef _DEBUG
/** We're in release, so let's advice compiler to inline this...
*
*
*/
inline const bool& Foo::IsBoolean() const
{
return _boolean;
}
#endif
And now, in Foo.cpp:
#include "Foo.h"
...
#ifdef _DEBUG
/** We're debugging this, no need for inlining...
*
*
*/
const bool& Foo::IsBoolean() const
{
return _boolean;
}
#endif
Is this completely useless? For example due to compiler's (MSVC) ability to inline / optimize methods all by itself?
Nevertheless, this is something I've been using for years now. Please correct me, if I'm completely wrong here...
It's a waste of time, for several reasons.
The inline keyword is a hint that the compiler may ignore at will. Just like it is free to inline even if the keyword is not specified. So whether or not you add it probably won't change anything for the compiler
Further, any functions defined inside the class definition are implicitly inlined. That is why short functions like getters and setters are almost always defined inside the class definition.
Next, if you want to mark a function as inline, there's no reason not to do it in debug builds as well.
The inline keyword has almost nothing to do with the compiler actually inlining functions. They are separate concepts. A function marked inline by the programmer means that the linker shouldn't worry if it sees multiple identical definitions. That typically happens if the function is defined in a header, which gets included into multiple compilation units. If the function is marked inline, the linker will merge the definitions together. If it isn't, you get an error. In other words, adding and removing this keyword will cause compiler errors. That's probably not what you want.
The only reason there is a bit of overlap between the C++ inline keyword and the compiler optimization is that if a function is marked inline, it is safe to #include it in every compilation unit, which means the definition will always be visible when the function is called. And that makes it easire for the compiler to inline calls to the function.
Finally, inlining is not always a performance improvement. It is easy to create a situation where inlining does nothing more than make the code size explode, cause more cache misses, and overall, slow down your code. That is one of the reasons why inline is (at best) treated as a hint by the optimizer. At worst, it is ignored entirely.
So what you're doing will 1) cause compiler errors in debug mode that didn't exist in release builds, and 2) have no effect on performance.
Looks like a waste of space and an unnecessary code duplication. Usually the compiler is very capable of determining on its own which functions to inline and which not. Even more so if you're using MSVC which has the /LTCG (Link Time Code Generation) switch that means your trivial methods are going to get inlined even if they are in the cpp.
The easiest thing to do what you want is to put the code into it's own file filename.inl and then conditionally include the file either into the header or the source file. You should also prefix the functions in the .inl file with a conditional macro that expands to inline if the file is included in to the header and to an empty macro otherwise.
Repetition is bad. Even if you're dealing with a brain-dead compiler, you can easily avoid this repetition, at worst, by using a macro INLINE defined in one place to either inline or nothing.