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.
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.
Wow, that's a lot of duplicate code if I understand this correctly. And just for the alone I'd say this is not a good thing. What a nightmare to maintain. =O
Just place the implementation in the .cpp file, and if you feel the need, mark the function as inline.
But yes, any decent compiler will inline anything it wants or ignore inlining on anything it does not want.
Work on clean design, and the compiler will have an easier time inlining anyway.
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.
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.