If you could define function by prepending `inline` in header file, why people recommend declare in header then define in a seperate .cpp file?

Question

So as I was learning, I was told that it's bad to define function within header files, as if it's included in multiple places, it'll produce multiple copies of that function and later causes error in linker. But later I found out that declaring such function with inline seems to prevent such issue, as stated in this SO answer, if using inline, the linker will make sure all functions points to the same address.

So if

1. inline is just a hint, and it won't force compiler to really inline a function.
2. inline will allow you to just declare functions within header files

Then why people bother to use the method "Declare function in header first, then define it in a seperate .cpp file", as such approach will require you to compile each .cpp and also ensure you provide all functions definition files when compiling the main code (something like g++ lib1.cpp lib2.cpp main.cpp).

As point 1 stated, even if your function is complicated and the compiler might not be able to optimize and inline it, wouldn't compiler just treat it as a normal function, and later make sure that linker links all calls to the correct, same address?

And unlike static, where each unit will have a copy of that function and will result in duplication of functions in executable, as told in the answer I linked above, it doesn't seem to be the case for inline. Which I don't see any disadvantage now to implement functions in .cpp file rather than just put it all in header.

• gnat: Does this answer your question? When a function should be declared inline in C++
• Andrew.Wolphoe: @gnat I don't think so, unless it really makes no difference. The answer you linked also point out that by specifying inline, it's actually suppressing the multiple copy linkage error, and also promising that all copies will be the same. What I'm asking is, if eventually, they'll be link (point) to the same function, then is there any pros/cons for doing it through specifying inline within header, or declare in header then define in .cpp?
• Filip Milovanović: See this answer. It's really a quirk of C++. Making everything inline has undesirable effects either way.
• amon: Header-only libraries are common and perfectly acceptable. You just have to be aware that this makes encapsulation quite difficult: in a header, there's no such thing as a private helper. You also won't be able to do incremental compilation, which really hurts when working on larger projects. It's often better to have the function definitions in their own compilation unit and then link them with your other code. If you want optimizations across compilation units you can enable LTO.
• Brandin: The problem that you seem to be trying to solve, of long compiler command lines, like "g++ blah1.cpp blah2.cpp blah3.cpp ..." is better solved by a build tool like make, cmake, etc. than by trying to use various language tricks in order to make your code compile with one command like "g++ my_huge_module.cpp". Header-only libraries notwithstanding, once programs get to be of non-trivial size, the rule you are mentioning (.h files to declare the interface, .cpp files to define the code) becomes an essential organisational tool.

Answer 1

Then why people bother to use the method "Declare function in header first, then define it in a seperate .cpp file" ...

It's partly about Separation of Concerns and partly about Timing:

Separation of Concerns:

• The .h file defines the interface that the library provides.
• The .cpp file contains the implementation to that interface that the library provides.

The Who, What and When of Compiling and Linking:

• The "supplier" of a library will commonly compile the .cpp file and produce an Object Library (.o) that is supplied to consumers, along with the header file. The consumer does not receive copies of the .cpp files and so (in theory) has no way of knowing the implementation details within the library and, more importantly, cannot "fiddle" with it.
• The "consumer" of a library needs to compile against the header file that defines the interface to the library and link against the Object Library to get a working executable.

If you define the "active" code directly in the .h file, then that code is "Out There", in The Wild. You lose control of it. Now, anyone with any sense would "let well alone" but there's absolutely nothing to stop someone trying to tweak [what was] your code or compile it with some "esoteric" options that means that the software that "you supplied" to them "doesn't work" on their machine.