I think you missed a couple of "can" and other qualifiers.
Maybe. I was reacting to a statement "I inline almost all
non-template function definitions." At one point, I did
qualify my statement with a "generally". The basic rule, of
course, is to prefer non-inline unless there is a good
reason for doing otherwise. There are sometimes good
reasons, and I'm the first to admit that if optimizing is
necessary, inlining (if that suffices) is a lot cheaper than
using some more complicated algorithm.
Especially for libraries of basic functionality, or in a
known "environment" where header pollution isn't an issue,
inlining is very useful for header-only modules without
introducing any extra coupling (coupling in addition to
what one already has anyway).
In certain contexts, yes. I tend to inline the virtual
destructor of an interface, for example---it does seem silly
to need to deliver an object file for one function, which by
definition will be empty, and is only present in order to
make it virtual.
As an example, one reason that much of Boost is so useful
is that a great many of the modules can be employed
without compiling them separately; just include the
relevant header and that's that.
That's a very important feature in Boost, because they've
adopted a build system which creates a lot of extra
problems. So you don't want to build it if you can avoid
it. The issue would be a lot less if they had a better
build system. And it's a non-issue if you get Boost
pre-installed (as you do with most Linux).
Note too that in a system library, which is presumably
stable, the "coupling" isn't so much an issue. If I change
the version of Boost (or the compiler, or the standard
library), I have to rebuild everything anyway. It's not
something I do very often, however, and it's something that
needs planning and scheduling---it's normally no problem to
schedule the rebuild on a week-end, so even compile times
aren't an issue.
So in a way inlining is the C++ counter-weight to the
language's lack of real modules.
For with real modules header-file modules would presumably
have had no advantage.
With real modules, the whole model would be different.
Basically, you would declare your "interface" (the publicly
accessible definitions) in one file, and your
"implementation" in as many different files as you want.
The compiler would take care of straightening things out.
You can, in fact, come fairly close to this in effect with
header files, as long as no templates are involved. But
there's always a bit of "playing with fire" involved.
